Traffic Director-Integration in Service Directory

Dieses Dokument bietet eine Übersicht über die Verwendung der Dienstregistrierung von Service Directory mit Traffic Director, mit der Traffic Director Traffic an Dienste weiterleiten kann, die bei Service Directory registriert sind. Dieses Dokument richtet sich an Traffic Director-Entwickler, die ihre Anwendungen in andere Dienste in Google Cloud integrieren möchten.

Service Directory ist eine Dienst-Registry, in der Informationen zu bei ihr registrierten Netzwerkdiensten gespeichert werden, einschließlich ihrer Namen, Standorte und Attribute. Sie können Ihre Dienste automatisch registrieren und alle Details erfassen. Außerdem können alle Dienste unabhängig von ihrer Infrastruktur registriert werden.

Die Registry kann nicht nur Google Cloud-Dienste, sondern auch lokal ausgeführte oder in anderen öffentlichen Clouds ausgeführte Hybrid-Dienste enthalten. Damit Sie die Informationen in diesem Dokument besser verstehen, sollten Sie sich mit den Grundlagen von Service Directory-Vorgängen vertraut machen.

Wenn Sie die Dienstregistrierung von Service Directory mit Traffic Director verwenden, stehen die Dienste in der Dienstregistrierung den Anwendungen in Ihrem Mesh und den von Traffic Director konfigurierten Gateways zur Verfügung. Die Einbindung von Traffic Director in Service Directory wird mit Envoy und mit proxylosem gRPC für Service Directory-Integrationen mit internen Passthrough-Network Load Balancern, internen Application Load Balancern und L4 Private Service Connect unterstützt.

Registrieren Sie einen Dienst bei Service Directory und binden Sie ihn dann an einen Backend-Dienst von Traffic Director, um Ihre Dienste einzubinden. Nachdem eine Bindung eingerichtet wurde, fragt Traffic Director Service Directory ab, um Informationen über den registrierten Dienst abzurufen und wie dieser Dienst erreicht werden kann. Traffic Director verfolgt auch alle Änderungen am Dienst. Durch Verwendung der Integration kann Ihr Service Mesh und Ihr selbstverwaltetes Gateway Traffic an diese Dienste senden. Außerdem können Sie Richtlinien erzwingen, z. B. erweiterte Richtlinien für die Trafficverwaltung, die Sie in Traffic Director konfigurieren.

Wenn Sie diese Integration verwenden, fungiert die Dienstbindung als Backend, unabhängig vom Typ des Backends, das vom Dienst selbst verwendet wird. Die Integration vereinfacht die Bereitstellung von Traffic Director, da Traffic Director ohne Berücksichtigung des Backend-Typs Traffic an den Dienst senden kann.

Wenn ein Dienst bei Service Directory registriert ist, müssen Sie keine Instanzgruppen oder verschiedenen Arten von Netzwerk-Endpunktgruppen (NEGs) konfigurieren, um Zugriff auf die benötigten Dienste zu erhalten. Sie können Google Kubernetes Engine, interne Load-Balancer und Private Service Connect automatisch bei Service Directory registrieren, um den Zugriff von Traffic Director auf diese Dienste weiter zu vereinfachen.

Von der Integration verwendete Ressourcen

Für die Integration zwischen Traffic Director und Service Directory werden die folgenden Ressourcen verwendet.

Service Directory-Dienste

Service Directory ist eine Dienst-Registry. Mit Service Directory können Sie verschiedene Arten von Diensten registrieren, einschließlich Diensten in Google Cloud oder anderen Umgebungen (z. B. einem lokalen Rechenzentrum). Jeder Dienst besteht aus einem eindeutigen Namen und null oder mehr Dienstendpunkten. Ein Dienstendpunkt besteht aus einer Adresse, einem Port, Attributen und Metadaten. Wenn keine Endpunkte vorhanden sind, können Sie den Traffic nicht an den Dienst weiterleiten.

Dienstbindungen

Eine Dienstbindung ist eine Ressource, die den vollständig qualifizierten Domainnamen (FQDN) des Service Directory-Dienstes enthält. Beispiel: projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service ist ein FQDN für einen Service Directory-Dienst.

Backend-Dienste

Backend-Dienste sind Konfigurationsressourcen, die Traffic Director einschließlich der Backends, z. B. verwalteter Instanzgruppen, an die der Backend-Dienst Traffic weiterleitet. Backend-Dienste, die auf Dienstbindungen verweisen, können keine Backends haben. Erstellen Sie einen neuen Backend-Dienst, um auf Dienstbindungen zu verweisen, um die Integration von Traffic Director in Service Directory zu verwenden.

Ein Backend-Dienst kann mehrere Dienstbindungen haben. Diese Konfiguration ist nützlich, wenn Sie regionale Bereitstellungen derselben Anwendung haben. Sie können jede regionale Bereitstellung in einer regionalen Instanz von Service Directory als regionalen Dienst 1 und regionaler Dienst 2 registrieren. Jeder dieser regionalen Service Directory-Dienste kann dann über zwei Dienstbindungen mit demselben Backend-Dienst verknüpft werden. Die globale Dienstbindung 1 wäre mit dem regionalen Dienst 1 in Region A und die globale Dienstbindung 2 mit dem regionalen Dienst 2 in Region B verknüpft.

Anwendungsfälle

Durch die Integration Ihrer Traffic Director-Bereitstellung in Service Directory können Sie neue Anwendungsfälle nutzen, wenn Sie Dienste nutzen, die anderen Teams oder Organisationen gehören oder veröffentlicht werden.

Vorhandene Dienste für Traffic Director verfügbar machen

Service Directory lässt sich in Google Cloud-Produkte wie GKE, interne Passthrough-Network Load Balancer und interne Application Load Balancer einbinden. Wenn Dienstersteller einen GKE-Dienst oder einen Load-Balancer erstellen, können sie diesen bei Service Directory registrieren.

Nachdem ein Dienst bei Service Directory registriert wurde, können Sie Traffic Director für die Kommunikation mit diesem Dienst konfigurieren. Traffic Director-Clients können dann mit Diensten kommunizieren, die hinter internen Passthrough-Network Load Balancern und internen Application Load Balancern ausgeführt werden.

Koordination zwischen Diensterstellern und Nutzern verbessern

Große Unternehmen haben viele unabhängige Entwicklerteams. Diese Teams stellen ihre Dienste für andere Teams zur Verfügung, sodass mehr Teams die Funktionen des freigegebenen Dienstes nutzen können. Dadurch werden teamübergreifende Abhängigkeiten erstellt. Diese Abhängigkeiten ermöglichen es Teams, ihre Aktivitäten gemeinsam zu nutzen, aber auch ein Koordinationsaufwand.

Wenn Sie Service Directory verwenden, kann ein Team (der Ersteller) registriert einen Dienst, der anderen Teams oder Organisationen zur Verfügung gestellt werden soll (Nutzer). Der Ersteller teilt einem Verweis auf diesen Dienst mit einem Nutzer. Der Nutzer kann diese Referenz verwenden, um den Dienst des Erstellers in Service Directory zu suchen und die Endpunkte des Dienstes zu ermitteln. Der Endpunkt kann beispielsweise eine virtuelle IP-Adresse (VIP) sein, über die der Dienst des Erstellers Traffic erwartet.

Durch die Einbindung von Traffic Director in Service Directory können Sie den Prozess automatisieren. Binden Sie dazu einen Service Directory-Dienst an einen Backend-Dienst von Traffic Director, was folgende Vorteile bietet:

  • Traffic Director löst die Dienstendpunkte automatisch durch Synchronisierung aus Service Directory auf. Wenn die Endpunkte des Service Directory-Dienstes aktualisiert werden, synchronisiert Traffic Director diese Änderungen automatisch.
  • Sie können in Traffic Director verschiedene Richtlinien für Routing und Trafficverwaltung festlegen, z. B. Zeitüberschreitungen. Mit diesen Richtlinien können Sie optimieren, wie Ihre Anwendungen Anfragen an den Service Directory-Dienst senden. Informationen zur Routing- und Trafficverwaltung in Traffic Director finden Sie unter Erweiterte Trafficverwaltung.
  • Traffic Director nutzt Trafficverwaltungsfunktionen wie umgebungsbasiertes Load-Balancing, um Traffic optimal von Anwendungen zu Endpunkten weiterzuleiten, z. B. durch Umlaufzeit.
Service Directory für die Diensterkennung verwenden
Service Directory für die Diensterkennung verwenden (zum Vergrößern klicken)

Wenn Sie als Nutzer Traffic Director verwenden und einen Backend-Dienst an einen Service Directory-Dienst anhängen, reduziert sich die teamübergreifende Koordination.

  • Sie hängen den Dienst Payments an den Namen an.

  • Traffic Director gibt Informationen zum Dienst Payments an seine Clients weiter.

    • Beispielsweise kennen die in Ihrem Service Mesh ausgeführten Sidecar-Proxys jetzt den Endpunkt (z. B. 10.0.0.1:80), an dem der Dienst erreichbar ist.

  • Ihre Anwendungen können diesen Dienst namentlich aufrufen, ohne dass Sie oder Ihre Anwendung etwas über den Endpunkt des externen Dienstes wissen müssen. Im Diagramm ist der Dienst Payments.

  • Wenn der Dienstersteller den externen Dienst aktualisiert (z. B. seinen Endpunkt ändert), ruft Traffic Director die Aktualisierung ab und gibt sie nahtlos für seine Clients frei.

Mit einem Ingress-Punkt auf Dienste in einem Perimeter zugreifen

Ein Team kann eine Sammlung von Diensten innerhalb eines VPC Service Controls-Perimeters gruppieren und diese Dienste über einen einzigen Eingangspunkt verfügbar machen. Dieser Ingress-Punkt kann in Service Directory registriert und Nutzern zur Verfügung gestellt werden, die auf die Dienste innerhalb des Perimeters zugreifen möchten. Weitere Informationen zu VPC Service Controls-Perimetern finden Sie unter Details zu Dienstperimetern und Konfigurationen.

Ein Team erstellt beispielsweise ein Ingress-Gateway mithilfe eines internen Application Load Balancers, der Anfragen an eine Sammlung von Kubernetes-Diensten in einem Cluster verteilt. Dieses Ingress-Gateway wird automatisch als Dienst in Service Directory registriert. Ein Nutzer, der auf die Kubernetes-Dienste zugreifen möchte, kann dieses Ingress-Gateway in Service Directory finden. Der Nutzer kann dann das Traffic Director-Mesh für den Zugriff auf Dienste innerhalb des Perimeters über das Gateway konfigurieren.

Dienste über mehrere Domains hinweg verbinden

Möglicherweise haben Sie Dienste in verschiedenen Domains, die Sie verbinden müssen.

Dienste organisationsübergreifend verbinden

Möglicherweise möchten Sie auf Dienste einer anderen Organisation zugreifen, z. B. Google APIs (z. B. Cloud SQL) oder verwaltete Dienste von Drittanbietern.

Service Directory unterstützt Private Service Connect. Wenn Sie in Ihrem Netzwerk einen Private Service Connect-Endpunkt erstellen, kann der Endpunkt als Dienst bei Service Directory registriert werden. Sie können diesen Dienst dann an Traffic Director anhängen, sodass Mesh-Clients wie Envoy- und gRPC-Clients und selbstverwaltete Gateways wie Apigee diese Dienste aufrufen können.

Service Directory für die Diensterkennung mit Private Service Connect verwenden.
Service Directory für die Diensterkennung mit Private Service Connect verwenden (zum Vergrößern klicken)

Das vorherige Beispiel mit Cloud Storage zeigt, wie Sie mit Private Service Connect Google APIs über einen Endpunkt in Ihrem Virtual Private Cloud-Netzwerk aufrufen können.

Dienste über VPC-Netzwerke verbinden

Einige Unternehmen verwenden im Rahmen ihrer Google Cloud-Bereitstellung mehrere VPC-Netzwerke. In solchen Fällen muss ein Dienst in einem VPC-Netzwerk möglicherweise auf einen Dienst in einem anderen VPC-Netzwerk zugreifen. Sie können das VPC-Peering für den Zugriff auf einen Dienst in einem anderen VPC-Netzwerk konfigurieren. Diese Konfiguration erstellt jedoch Komplikationen, wenn sich die IP-Adressbereiche zwischen den Peering-Netzwerken überschneiden.

Private Service Connect kann einen Dienst in einem VPC-Netzwerk sicher und privat über einen einzelnen IP:port-Endpunkt für Dienste in einem anderen VPC-Netzwerk zugänglich machen.

Detaillierte Ansicht der Verwendung von Service Directory für die Diensterkennung mit Private Service Connect.
Detaillierte Ansicht der Verwendung von Service Directory für die Diensterkennung mit Private Service Connect (zum Vergrößern klicken)

Weitere Beispiele domainübergreifend

Die vorherigen zwei Beispiele zeigen Fälle, in denen Sie möglicherweise Domains verknüpfen müssen, aber es gibt viele zusätzliche Beispiele. Sie können beispielsweise ein Gateway erstellen, das sich am Schnittpunkt von zwei Google Cloud-Regionen befindet. Dienste in einer Region können über dieses Gateway Dienste in einer anderen Region erreichen. Sie registrieren das Gateway als Dienst in Service Directory und verwenden dann das Gateway wie in diesem Dokument beschrieben mit Traffic Director.

Richtlinien anwenden, wenn auf Dienste zugegriffen wird

Traffic Director unterstützt Funktionen wie die erweiterte Trafficverwaltung, die mithilfe von Richtlinien konfiguriert werden können. Sie können beispielsweise eine Richtlinie für die Trafficspiegelung festlegen, sodass der Traffic immer dann an einen zweiten Backend-Dienst gesendet wird, wenn ein Client eine Anfrage an einen bestimmten Backend-Dienst sendet.

Wenn Sie einen Service Directory-Dienst an einen Traffic Director-Backend-Dienst binden, können Sie diese Richtlinientypen in Traffic Director konfigurieren. Ihre Sidecar-Proxys, mittleren oder Edge-Proxys und proxylose Clients erfahren diese Richtlinien und setzen sie durch.

Einige Beispiele:

  • Gewichtete Trafficaufteilung, z. B. zwischen zwei Service Directory-Diensten
  • Trafficspiegelung, z. B. zu einem Auditdienst
Anfragen für den Dienst "users" werden an den Dienst "audit" gespiegelt
Anfragen für den Dienst users werden an den Dienst audit gespiegelt (zum Vergrößern klicken)

Unterstützung für Traffic Director und vorhandene Clients

Auch wenn Traffic Director in Ihrer Organisation bereitgestellt wird, haben Sie möglicherweise Clients, die Traffic Director nicht verwenden. Beispielsweise müssen Sie möglicherweise auf einen Dienst von einer virtuellen Maschine aus zugreifen, die nicht Teil eines Service Mesh ist.

Wenn Sie einen Service Directory-Dienst an einen Backend-Dienst von Traffic Director binden, erhalten die Clients von Traffic Director automatisch aktuelle Informationen zu diesem Dienst. Ihre Clients, die Traffic Director nicht verwenden, können Dienstinformationen in Service Directory suchen und verwenden.

Beschränkungen

Traffic Director unterstützt in der Service Directory-Integration keine FQDN-NEGs (INTERNET_FQDN_PORT NEGs).

Nächste Schritte