APISIX Ingress Controller s'intègre à la découverte de services

La découverte de services est-elle nécessaire dans les applications cloud-natives ?

Contexte

L'architecture microservices est l'une des architectures d'application les plus populaires aujourd'hui. Avec l'augmentation de la taille des applications, la gestion de l'application devient plus difficile. L'architecture microservices tente de résoudre ce problème en divisant l'application en plusieurs composants de service plus petits, qui coopèrent ensemble pour accomplir la logique métier et les fonctions spécifiques.

Ces composants doivent communiquer dynamiquement pour bien fonctionner ensemble. Il est généralement nécessaire d'introduire des outils de découverte de services. Nous avons écrit un article présentant la découverte de services dans les microservices plus tôt : Qu'est-ce que la découverte de services dans les microservices - API7.ai.

En introduisant la découverte de services, les composants peuvent être obtenus dynamiquement. Ils n'ont besoin de prêter attention qu'aux noms des autres composants sans se soucier d'autres informations telles que l'emplacement de déploiement ou l'IP de déploiement.

Découverte de services dans Kubernetes

Dans l'environnement Kubernetes, les pods sont la plus petite unité déployable.

Et dans Kubernetes, les composants ont plus de difficultés à communiquer entre eux car l'IP du Pod n'est pas persistante et change souvent.

Par conséquent, il est encore plus important de s'adapter à cet environnement dynamique lors du déploiement d'applications dans Kubernetes.

Kubernetes prend en compte cette exigence et fournit son propre mécanisme de découverte de services basé sur DNS.

Kubernetes fournit un concept appelé Service, similaire à un proxy inverse. Le client n'a besoin que d'utiliser le Service et n'a pas besoin de connaître les pods encapsulés derrière.

Chaque Service se voit attribuer une ClusterIP persistante. Ainsi, lorsque l'IP du pod change, les autres composants peuvent toujours collaborer via la ClusterIP fixe du Service.

En même temps, le service dans Kubernetes mettra automatiquement à jour un enregistrement A/AAAA dans le DNS du cluster.

L'enregistrement ressemble à :

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

Le client peut résoudre entre les espaces de noms ou dans le même espace de noms, ce qui facilite grandement la découverte de services entre les composants.

Cependant, pour l'architecture microservices traditionnelle qui n'est pas dans Kubernetes, nous utilisons généralement des outils de découverte de services pour réaliser la collaboration entre les services. Pour s'adapter pleinement au mécanisme de découverte de services basé sur DNS dans l'environnement Kubernetes, un certain coût de transformation/migration est nécessaire.

Par conséquent, vous devez maintenir le mécanisme de découverte de services d'origine si vous souhaitez des coûts de transformation plus faibles.

Dans cette optique, quelle est la meilleure façon d'exposer les services nouvellement migrés vers Kubernetes ?

Comment APISIX Ingress fonctionne-t-il avec la découverte de services ?

APISIX Ingress est une implémentation du contrôleur Ingress dans Kubernetes. Il utilise Apache APISIX comme plan de données et prend en charge la configuration des règles de proxy via Ingress, CRD personnalisé et Gateway API. En même temps, il fournit également une intégration avec des outils de découverte de services, ce qui facilite le proxy des services enregistrés et leur exposition au client.

Nous l'expliquerons en détail dans cette section.

Support de la découverte de services par APISIX

APISIX est une passerelle API cloud-native haute performance et entièrement dynamique qui fournit plus de 80 plugins prêts à l'emploi, couvrant la plupart des scénarios d'utilisation.

L'une des excellentes capacités est l'intégration avec des outils de découverte de services.

APISIX peut être intégré avec les outils de découverte de services suivants :

• Consul
• DNS
• Eureka
• Nacos

Il suffit d'ajouter la configuration suivante au fichier de configuration d'APISIX (prenons DNS comme exemple) :

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # utilisez l'adresse réelle de votre serveur DNS

De cette façon, lors de la configuration de l'upstream, APISIX peut résoudre dynamiquement les informations d'adresse réelle de l'upstream via la découverte de services et proxy la requête.

Comment APISIX Ingress le fait-il ?

APISIX Ingress utilise APISIX comme composant proxy du plan de données. Lors de la première intégration de la découverte de services, nous avons envisagé deux options.

• Intégration du plan de contrôle : configurer la découverte de services dans le contrôleur Ingress, analyser et interpréter la configuration, et envoyer les résultats à APISIX pour le proxy.
• Intégration du plan de données : configurer la découverte de services sur le plan de données d'APISIX, et le plan de données effectue l'analyse et le proxy de la configuration.

Ces deux solutions ont leurs propres avantages, mais en considérant la mise à jour en temps réel de la configuration et la maturité de la solution, nous avons choisi la solution d'intégration du plan de données.

En utilisant cette solution, les utilisateurs peuvent l'intégrer à moindre coût, et cette solution est assez mature et a subi de nombreuses vérifications en production.

Comment utiliser APISIX Ingress ?

Tout d'abord, assurez-vous que la configuration correcte de la découverte de services a été incluse dans la configuration d'APISIX. Voici un exemple avec DNS :

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

Créez une ressource ApisixUpstream, et modifiez sa configuration liée à discovery selon le scénario d'utilisation. Par exemple, type: dns et serviceName à proxier sont définis ici :

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

Enfin, créez une ressource ApisixRoute dont les upstreams font référence à la ressource ApisixUpstream créée précédemment :

# 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

Après la création correcte des ressources ci-dessus, vous pouvez accéder à httpbin.default.svc.cluster.local enregistré dans DNS via local.httpbin.org.

Avantages et perspectives

Grâce à cette intégration, il est très pratique d'exposer des services aux clients via APISIX Ingress pour les applications qui utilisent déjà des outils de découverte de services. Cette fonctionnalité d'APISIX Ingress est distinctive car la plupart des contrôleurs Ingress ne fournissent pas cette solution d'intégration.

Merci de votre lecture. Nous sommes toujours en train de construire APISIX Ingress pour offrir les meilleures expériences utilisateur !

Pour plus d'informations sur la passerelle API, veuillez visiter notre blog ou nous contacter.