Service Discovery

Dieses Dokument enthält eine Übersicht über DNS-basierte Kubernetes Service Discovery und die Verwendung mit Kf.

Verwendung von Kubernetes Service Discovery mit Kf

Kubernetes Service Discovery kann von Anwendungen verwendet werden, die unterstützende Dienste auf konsistente Weise finden sollen, unabhängig davon, wo die Anwendung bereitgestellt wird. Beispiel: Ein Team möchte für die Konfiguration einen gemeinsamen URI verwenden, der immer auf das lokale SMTP-Gateway verweist, um den Code von der Umgebung zu trennen, in der er ausgeführt wurde.

Service Discovery unterstützt Anwendungsteams bei folgenden Aufgaben:

  • Konfigurationsaufwand pro Umgebung reduzieren
  • Client- und Serveranwendungen entkoppeln
  • Möglichkeit, Anwendungen in neue Umgebungen zu übertragen

Sie können Kubernetes Service Discovery in folgenden Fällen verwenden:

  • Wenn Anwendungen die DNS-Konfigurationen ihres Containers nutzen, um Hosts aufzulösen
  • Wenn Anwendungen mit ihren unterstützenden Diensten im selben Kubernetes-Cluster oder ‑Namespace bereitgestellt werden
  • Wenn unterstützende Dienste mit einem Kubernetes-Dienst verknüpft sind (Kf erstellt diese unterstützenden Dienste für jede Anwendung)
  • Wenn Kubernetes-Netzwerkrichtlinien Traffic zwischen einer Anwendung und dem Kubernetes-Dienst zulassen, mit dem sie kommunizieren muss (Kf erstellt diese Richtlinien in jedem Kf-Bereich)

In folgenden Fällen sollten Sie Kubernetes Service Discovery nicht verwenden:

  • Wenn Anwendungen einen Failover zwischen mehreren Clustern ausführen müssen
  • Wenn Sie den von Ihrer Anwendung verwendeten DNS-Resolver überschreiben
  • Wenn Anwendungen bestimmte Arten von Load Balancing erfordern

Funktionsweise von Kubernetes Service Discovery

Kubernetes Service Discovery funktioniert durch Ändern der DNS-Konfiguration von Containern, die auf einem Kubernetes-Knoten ausgeführt werden. Wenn eine Anwendung nach einem nicht qualifizierten Domainnamen sucht, versucht der lokale DNS-Resolver zuerst, den Namen im lokalen Cluster aufzulösen.

Domains, die nicht aus mehreren Elementen bestehen, werden für die Namen von Kubernetes-Diensten im Namespace des Containers aufgelöst. Jede Kf-Anwendung erstellt einen Kubernetes-Dienst mit dem gleichen Namen. Wenn die beiden Kf-Anwendungen ping und pong im selben Kf-Bereich bereitgestellt wurden, kann ping mit der URL http://pong Traffic an den anderen Dienst senden.

Domains mit einem einzelnen Punkt werden für die Kubernetes-Dienste im Kubernetes-Namespace aufgelöst, der den gleichen Namen wie das Label nach dem Punkt hat. Wenn beispielsweise eine PostgreSQL-Datenbank mit dem Dienst customers im Namespace database vorhanden ist, kann eine Anwendung in einem anderen Namespace sie mithilfe von postgres://customers.database auflösen.

Service Discovery mit Kf verwenden

DNS-basierte Kubernetes Service Discovery kann für jede Kf-Anwendung verwendet werden. Jede Kf-Anwendung erstellt einen Kubernetes-Dienst mit dem gleichen Namen und jeder Kf-Bereich erstellt einen Kubernetes-Namespace mit dem gleichen Namen.

  • Mit protocol://app-name verweisen Sie auf eine Kf-Anwendung im aktuellen Bereich.
  • Mit protocol://app-name.space-name verweisen Sie auf eine Kf-Anwendung in einem anderen Bereich.
  • Mit protocol://app-name:port verweisen Sie auf eine Kf-Anwendung im aktuellen Bereich, die einen benutzerdefinierten Port überwacht.
  • Mit protocol://app-name.space-name:port verweisen Sie auf eine Kf-Anwendung in einem anderen Bereich, die einen benutzerdefinierten Port überwacht.

Best Practices

Für Anwendungen, die das Ziel von DNS-basierter Service Discovery sind, sollten häufig Systemdiagnosen durchgeführt werden. Dies sorgt dafür, dass sie dem Pool von Hosts, die Verbindungen akzeptieren, schnell hinzugefügt und wieder daraus entfernt werden.

Anwendungen, die DNS-basierte Service Discovery verwenden, sollten die IP-Adressen der aufgelösten Dienste nicht im Cache speichern, da nicht gewährleistet werden kann, dass sie stabil sind.

Wenn umgebungsspezifische Dienste außerhalb des Clusters vorhanden sind, können diese mit Kubernetes DNS aufgelöst werden. Dazu müssen Sie Kubernetes-Dienste vom Typ ExternalName einrichten. Diese Kubernetes-Dienste bieten die gleichen Auflösungsfunktionen, geben aber einen CNAME-Eintrag zurück, um Anfragen an eine externe Stelle weiterzuleiten.

Vergleich mit Eureka

Eureka ist ein clientseitiger Open-Source-Load Balancer von Netflix. Er wird häufig im Rahmen des Service Brokers von Spring Cloud-Diensten verwendet. Eureka wurde als regionaler Load Balancer und Service Discovery-Mechanismus entwickelt. Es ist für Dienste geeignet, die in einer Umgebung ausgeführt werden, in der häufig Störungen von Arbeitslasten auftreten, die zu instabilen IP-Adressen führen.

Eureka wurde als Client-Server-Modell konzipiert. Clients registrieren sich dabei selbst beim Server, geben an, mit welchen Namen sie verknüpft werden sollen, und senden regelmäßig Server-Heartbeats. Der Server ermöglicht allen verbundenen Clients, Namen aufzulösen.

Sie sollten in Kubernetes aus folgenden Gründen Kubernetes DNS statt Eureka verwenden:

  • DNS funktioniert mit allen Programmiersprachen und Anwendungen, ohne dass Bibliotheken erforderlich sind.
  • Die vorhandene Systemdiagnose der Anwendung wird wiederverwendet, um Kombinationen von Fehlern zu reduzieren.
  • Kubernetes verwaltet den DNS-Server, sodass weniger Abhängigkeiten notwendig sind.
  • Kubernetes DNS folgt den gleichen Richtlinien und RBAC-Einschränkungen wie der Rest von Kubernetes.

Das Bereitstellen eines Eureka-Servers hat aber in folgenden Fällen Vorteile:

  • Sie benötigen Service Discovery in Kubernetes- und VM-basierten Anwendungen.
  • Sie benötigen clientbasiertes Load Balancing.
  • Sie benötigen unabhängige Systemdiagnosen.

Weitere Informationen