Diensterkennung

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.

  • Verweisen Sie mit protocol://app-name auf eine Kf-Anwendung im aktuellen Bereich.
  • Verweisen Sie mit protocol://app-name.space-name auf eine Kf-Anwendung in einem anderen Bereich.
  • Verweisen Sie mit protocol://app-name:port auf eine Kf-Anwendung im aktuellen Bereich, die einen benutzerdefinierten Port überwacht.
  • Verweisen Sie mit protocol://app-name.space-name:port 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, weil ihre Stabilität nicht zugesichert werden kann.

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 am Server, um anzugeben, mit welchen Namen sie verknüpft werden sollen, und senden regelmäßig Server-Heartbeats. Der Server ermöglicht allen verbundenen Clients, Namen aufzulösen.

Aus den folgenden Gründen sollten Sie Kubernetes DNS statt Eureka in Kubernetes 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 vorhanden sind.
  • Kubernetes DNS folgt den gleichen Richtlinien und RBAC-Einschränkungen wie der Rest von Kubernetes.

Das Bereitstellen eines Eureka-Servers kann aber in folgenden Fällen von Vorteil sein:

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

Weitere Informationen