APISIX Ingress Controller se integra con Service Discovery

¿Es necesario el descubrimiento de servicios en aplicaciones nativas de la nube?

Antecedentes

La arquitectura de microservicios es una de las arquitecturas de aplicaciones más populares en la actualidad. Con el aumento del tamaño de las aplicaciones, la gestión de las mismas se vuelve más difícil. La arquitectura de microservicios intenta resolver este problema dividiendo la aplicación en múltiples componentes de servicio más pequeños, que cooperan entre sí para completar la lógica y funciones comerciales específicas.

Estos componentes deben comunicarse dinámicamente para funcionar bien juntos. Por lo general, es necesario introducir herramientas de descubrimiento de servicios. Escribimos un artículo anteriormente que introduce el descubrimiento de servicios en microservicios: ¿Qué es el descubrimiento de servicios en microservicios? - API7.ai.

Al introducir el descubrimiento de servicios, los componentes pueden obtenerse dinámicamente. Solo necesitan prestar atención a los nombres de otros componentes sin preocuparse por otra información como la ubicación de implementación o la IP de implementación.

Descubrimiento de servicios en Kubernetes

En el entorno de Kubernetes, los pods son la unidad de implementación más pequeña.

Y en Kubernetes, es más difícil que los componentes se comuniquen entre sí porque la IP del Pod no es persistente y cambia con frecuencia.

Por lo tanto, es aún más importante adaptarse a este entorno dinámico al implementar aplicaciones en Kubernetes.

Kubernetes considera este requisito y proporciona su propio mecanismo de descubrimiento de servicios basado en DNS.

Kubernetes proporciona un concepto llamado Service, similar a un proxy inverso. El cliente solo necesita usar el Service y no necesita conocer los pods encapsulados detrás.

Cada Service recibirá una ClusterIP persistente. Por lo tanto, cuando la IP del pod cambia, otros componentes aún pueden colaborar a través de la ClusterIP fija del Service.

Al mismo tiempo, el Service en Kubernetes actualizará automáticamente un registro A/AAAA en el DNS del clúster.

El registro se ve así:

my-svc.my-namespace.svc.cluster-domain.example

El cliente puede resolver a través de namespaces o en el mismo namespace, lo que facilita enormemente el descubrimiento de servicios entre componentes.

Sin embargo, para la arquitectura de microservicios tradicional que no está en Kubernetes, generalmente usamos herramientas de descubrimiento de servicios para lograr la colaboración entre servicios. Para adaptarse completamente al mecanismo de descubrimiento de servicios basado en DNS en el entorno de Kubernetes, se requiere un cierto costo de transformación/migración.

Por lo tanto, debes mantener el mecanismo de descubrimiento de servicios original si deseas costos de transformación más bajos.

Bajo esta premisa, ¿cuál es la mejor manera de exponer los servicios recién migrados a Kubernetes?

¿Cómo funciona APISIX Ingress con el descubrimiento de servicios?

APISIX Ingress es una implementación del controlador Ingress en Kubernetes. Utiliza Apache APISIX como el plano de datos y admite la configuración de reglas de proxy a través de Ingress, CRD personalizados y Gateway API. Al mismo tiempo, también proporciona integración con herramientas de descubrimiento de servicios, lo que facilita el proxy de los servicios registrados y su exposición al cliente.

Lo explicaremos en detalle en esta sección.

Soporte de APISIX para el descubrimiento de servicios

APISIX es una puerta de enlace API nativa de la nube de alto rendimiento y completamente dinámica que proporciona más de 80 complementos listos para usar, cubriendo la mayoría de los escenarios de uso.

Una de las excelentes capacidades es la integración con herramientas de descubrimiento de servicios.

APISIX puede integrarse con las siguientes herramientas de descubrimiento de servicios:

• Consul
• DNS
• Eureka
• Nacos

Solo agrega la siguiente configuración al archivo de configuración de APISIX (tomando DNS como ejemplo):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # usa la dirección real de tu servidor DNS

De esta manera, al configurar el upstream, APISIX puede resolver dinámicamente la información de la dirección upstream real a través del descubrimiento de servicios y hacer proxy de la solicitud.

¿Cómo lo hace APISIX Ingress?

APISIX Ingress utiliza APISIX como el componente de proxy del plano de datos. Al integrar por primera vez el descubrimiento de servicios, consideramos dos opciones.

• Integración en el plano de control: configurar el descubrimiento de servicios en el controlador Ingress, analizar y analizar la configuración, y enviar los resultados a APISIX para el proxy.
• Integración en el plano de datos: configurar el descubrimiento de servicios en el plano de datos de APISIX, y el plano de datos realiza el análisis de configuración y el proxy.

Estas dos soluciones tienen sus propias ventajas, pero considerando la actualización en tiempo real de la configuración y la madurez de la solución, elegimos la solución de integración en el plano de datos.

Al usar esta solución, los usuarios pueden integrarla a un costo más bajo, y esta solución es bastante madura que ha pasado por muchas verificaciones de producción.

¿Cómo usar APISIX Ingress?

Primero, asegúrate de que la configuración correcta de descubrimiento de servicios se haya incluido en la configuración de APISIX. El siguiente ejemplo usa DNS:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

Crea un recurso ApisixUpstream y modifica su configuración relacionada con discovery según el escenario de uso. Por ejemplo, aquí se configuran type: dns y serviceName para el proxy:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

Finalmente, crea un recurso ApisixRoute cuyo upstreams haga referencia al recurso ApisixUpstream recién creado:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

Después de crear correctamente los recursos anteriores, puedes acceder a httpbin.default.svc.cluster.local registrado en DNS a través de local.httpbin.org.

Beneficios y perspectivas

A través de esta integración, es muy conveniente exponer servicios a los clientes a través de APISIX Ingress para aplicaciones que ya están utilizando herramientas de descubrimiento de servicios. Esta característica de APISIX Ingress es distintiva, ya que la mayoría de los controladores Ingress no proporcionan esta solución de integración.

Gracias por leer. ¡Seguimos en el camino de construir APISIX Ingress para ofrecer las mejores experiencias de usuario!

Para obtener más información sobre la puerta de enlace API, visita nuestros blogs o contáctanos.