APISIX Ingress Controller integriert sich mit Service Discovery

Ist Service Discovery in Cloud-Nativen Anwendungen erforderlich?

Hintergrund

Microservice-Architektur ist eine der beliebtesten Anwendungsarchitekturen heutzutage. Mit der Zunahme der Anwendungsgrößen wird die Verwaltung der Anwendung schwieriger. Die Microservice-Architektur versucht, dieses Problem zu lösen, indem die Anwendung in mehrere kleinere Dienstkomponenten aufgeteilt wird, die zusammenarbeiten, um die spezifische Geschäftslogik und Funktionen zu erfüllen.

Diese Komponenten müssen dynamisch kommunizieren, um gut zusammenzuarbeiten. Es ist in der Regel notwendig, Service-Discovery-Tools einzuführen. Wir haben bereits einen Artikel über Service Discovery in Microservices geschrieben: Was ist Service Discovery in Microservices - API7.ai.

Durch die Einführung von Service Discovery können Komponenten dynamisch abgerufen werden. Sie müssen sich nur auf die Namen anderer Komponenten konzentrieren, ohne sich um andere Informationen wie den Bereitstellungsort oder die Bereitstellungs-IP kümmern zu müssen.

Service Discovery in Kubernetes

In der Kubernetes-Umgebung sind Pods die kleinste bereitstellbare Einheit.

Und in Kubernetes ist die Kommunikation zwischen Komponenten schwieriger, da die IP des Pods nicht persistent ist und sich häufig ändert.

Daher ist es noch wichtiger, sich an diese dynamische Umgebung anzupassen, wenn Anwendungen in Kubernetes bereitgestellt werden.

Kubernetes berücksichtigt diese Anforderung und bietet einen eigenen DNS-basierten Service-Discovery-Mechanismus.

Kubernetes bietet ein Konzept namens Service, das einem Reverse-Proxy ähnelt. Der Client muss nur den Service verwenden und muss die dahinter gekapselten Pods nicht kennen.

Jeder Service erhält eine persistente ClusterIP. Wenn sich also die Pod-IP ändert, können andere Komponenten weiterhin über die feste ClusterIP des Services zusammenarbeiten.

Gleichzeitig aktualisiert der Service in Kubernetes automatisch einen A/AAAA-Eintrag im DNS des Clusters.

Der Eintrag sieht so aus:

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

Der Client kann über Namespaces hinweg oder im selben Namespace auflösen, was die Service Discovery zwischen Komponenten erheblich erleichtert.

Für die traditionelle Microservice-Architektur, die nicht in Kubernetes läuft, verwenden wir jedoch in der Regel Service-Discovery-Tools, um die Zusammenarbeit zwischen Diensten zu ermöglichen. Um sich vollständig an den DNS-basierten Service-Discovery-Mechanismus in der Kubernetes-Umgebung anzupassen, sind bestimmte Anpassungs-/Migrationskosten erforderlich.

Daher müssen Sie den ursprünglichen Service-Discovery-Mechanismus beibehalten, wenn Sie niedrigere Anpassungskosten wünschen.

Unter dieser Voraussetzung, was ist der beste Weg, um neu nach Kubernetes migrierte Dienste verfügbar zu machen?

Wie funktioniert APISIX Ingress mit Service Discovery?

APISIX Ingress ist eine Implementierung des Ingress-Controllers in Kubernetes. Es verwendet Apache APISIX als Datenebene und unterstützt die Konfiguration von Proxy-Regeln über Ingress, benutzerdefinierte CRD und die Gateway-API. Gleichzeitig bietet es auch eine Integration mit Service-Discovery-Tools, was es einfach macht, die registrierten Dienste zu proxen und sie dem Client verfügbar zu machen.

Wir werden dies in diesem Abschnitt detailliert erklären.

APISIX-Unterstützung für Service Discovery

APISIX ist ein hochleistungsfähiges, vollständig dynamisches Cloud-natives API-Gateway, das über 80 Plugins bietet, die die meisten Anwendungsfälle abdecken.

Eine der hervorragenden Fähigkeiten ist die Integration mit Service-Discovery-Tools.

APISIX kann mit den folgenden Service-Discovery-Tools integriert werden:

• Consul
• DNS
• Eureka
• Nacos

Fügen Sie einfach die folgende Konfiguration zur APISIX-Konfigurationsdatei hinzu (DNS als Beispiel):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # verwenden Sie die echte Adresse Ihres DNS-Servers

Auf diese Weise kann APISIX bei der Konfiguration des Upstreams die tatsächlichen Upstream-Adressinformationen dynamisch über Service Discovery auflösen und die Anfrage proxen.

Wie macht APISIX Ingress das?

APISIX Ingress verwendet APISIX als Datenebenen-Proxy-Komponente. Bei der ersten Integration von Service Discovery haben wir zwei Optionen in Betracht gezogen.

• Integration der Steuerungsebene: Konfigurieren Sie Service Discovery im Ingress-Controller, analysieren und analysieren Sie die Konfiguration und senden Sie die Ergebnisse an APISIX zur Weiterleitung.
• Integration der Datenebene: Konfigurieren Sie Service Discovery auf der APISIX-Datenebene, und die Datenebene führt die Konfigurationsanalyse und Weiterleitung durch.

Diese beiden Lösungen haben ihre eigenen Vorteile, aber unter Berücksichtigung der Echtzeitaktualisierung der Konfiguration und der Reife der Lösung haben wir uns für die Integration der Datenebene entschieden.

Bei Verwendung dieser Lösung können Benutzer sie mit geringeren Kosten integrieren, und diese Lösung ist recht ausgereift und hat viele Produktionsüberprüfungen durchlaufen.

Wie verwendet man APISIX Ingress?

Stellen Sie zunächst sicher, dass die richtige Service-Discovery-Konfiguration in der APISIX-Konfiguration enthalten ist. Das Folgende verwendet DNS als Beispiel:

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

Erstellen Sie eine ApisixUpstream-Ressource und passen Sie deren Konfiguration im Zusammenhang mit discovery gemäß dem Anwendungsfall an. Hier werden beispielsweise type: dns und der zu proxyende serviceName festgelegt:

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

Erstellen Sie schließlich eine ApisixRoute-Ressource, deren upstreams auf die gerade erstellte ApisixUpstream-Ressource verweist:

# 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

Nachdem die oben genannten Ressourcen korrekt erstellt wurden, können Sie über local.httpbin.org auf httpbin.default.svc.cluster.local zugreifen, das im DNS registriert ist.

Vorteile und Ausblick

Durch diese Integration ist es sehr bequem, Dienste über APISIX Ingress für Anwendungen, die bereits Service-Discovery-Tools verwenden, für Clients verfügbar zu machen. Diese APISIX-Ingress-Funktion ist besonders, da die meisten Ingress-Controller diese Integrationslösung nicht bieten.

Vielen Dank fürs Lesen. Wir sind immer noch dabei, APISIX Ingress zu entwickeln, um die besten Benutzererfahrungen zu bieten!

Weitere Informationen über API-Gateways finden Sie in unseren Blogs oder kontaktieren Sie uns.