Einbindung von Cloud Service Mesh in Service Directory
Dieses Dokument bietet einen Überblick über die Verwendung Service Directory Dienstregistrierung mit Cloud Service Mesh, mit der Cloud Service Mesh Traffic weiterleiten kann und Trafficrichtlinien auf Dienste anwenden, die bei Service Directory registriert sind. Dieses Dokument richtet sich an Cloud Service Mesh-Entwickler, die ihre mit anderen Diensten in Google Cloud kombinieren.
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 Service Directory-Dienstregistrierung von Service Directory mit Cloud Service Mesh erstellt, werden durch die Einbindung Dienste in der Dienst-Registry erstellt. für die Anwendungen in Ihrem Mesh-Netzwerk und für Gateways verfügbar, die von Cloud Service Mesh. Cloud Service Mesh-Einbindung in Service Directory wird von Envoy und mit proxylosem Dienst unterstützt gRPC für Service Directory-Integrationen mit Interne Passthrough-Network Load Balancer, interne Application Load Balancer und L4 Private Service Connect
Zur Integration Ihrer Dienste registrieren Sie einen Dienst bei Service Directory (Dienstverzeichnis) und binden Sie den Dienst dann an ein Cloud Service Mesh. Back-End-Dienst. Nachdem eine Bindung eingerichtet wurde, fragt Cloud Service Mesh ab Service Directory, um Informationen zur registrierten und wie er erreicht werden kann. Cloud Service Mesh 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 damit wie erweiterte Richtlinien für die Traffic-Verwaltung, die Sie in Cloud Service Mesh 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 Ihrer Cloud Service Mesh-Bereitstellung, da Cloud Service Mesh Traffic ohne Rücksicht auf den Back-End-Typ.
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 sich automatisch registrieren, Google Kubernetes Engine, interne Load-Balancer und Private Service Connect zu Service Directory führen, was die auf diese Dienste zugreifen können.
Von der Integration verwendete Ressourcen
Integration zwischen Cloud Service Mesh und Service Directory verwendet die folgenden Ressourcen.
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 keinen Traffic weiterleiten für den Dienst.
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
Back-End-Dienste sind Konfigurationsressourcen, die Informationen Cloud Service Mesh, einschließlich Back-Ends wie verwalteten Instanzgruppen, über den der Back-End-Dienst den Traffic weiterleitet. Backend-Dienste, die auf Dienstbindungen verweisen, können keine Backends haben. So verwenden Sie die Cloud Service Mesh-Integration erstellen Sie einen neuen Back-End-Dienst, auf Dienstbindungen verweisen.
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
Cloud Service Mesh-Bereitstellung in Service Directory einbinden ermöglicht neue Anwendungsfälle, die hilfreich sind, wenn Sie auf Dienste angewiesen sind, die andere die Teams oder Organisationen besitzen oder veröffentlichen.
Vorhandene Dienste für Cloud Service Mesh verfügbar machen
Service Directory ist in Google Cloud-Produkte eingebunden wie GKE, interne Passthrough-Network Load Balancer und interne Application Load Balancer. 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 Cloud Service Mesh für die Kommunikation mit diesem Dienst konfigurieren. Cloud-Service-Mesh können Kunden dann mit Diensten kommunizieren, internen Passthrough-Network Load Balancern und internen Application Load Balancern.
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 Cloud Service Mesh in Service Directory können Sie Prozess zu automatisieren, indem Sie einen Service Directory-Dienst an einen Cloud Service Mesh-Back-End-Dienst, der die folgenden Vorteile bietet:
- Cloud Service Mesh löst die Endpunkte des Dienstes automatisch auf, indem um sie aus Service Directory zu synchronisieren. Wenn die Die Endpunkte des Service Directory-Diensts Cloud Service Mesh synchronisiert diese Änderungen automatisch.
- Sie können verschiedene Richtlinien für die Weiterleitung und Trafficverwaltung festlegen, z. B. Zeitüberschreitungen in Cloud Service Mesh. Mit diesen Richtlinien können Sie optimieren, wie Ihre Anwendungen Anfragen an den Service Directory-Dienst senden. Für Informationen zum Routing und zur Trafficverwaltung in Cloud Service Mesh finden Sie unter Erweiterte Traffic-Verwaltung:
- Cloud Service Mesh nutzt Traffic-Verwaltungsfunktionen wie nahrungsbasiertes Load-Balancing, um Traffic optimal von Anwendungen auf Endpunkte zu übertragen, z. B. durch Minimieren der Umlaufzeit.
Wenn Sie ein Nutzer sind, verwenden Sie Cloud Service Mesh und hängen Sie einen Back-End-Dienst an Service Directory-Dienst ist, ist der teamübergreifende Koordinationsaufwand reduziert.
- Sie hängen den Dienst
Paymentsan den Namen an. Cloud Service Mesh gibt Informationen zum Dienst
Paymentsan seine Kundschaft.- 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.
- Beispielsweise kennen die in Ihrem Service Mesh ausgeführten Sidecar-Proxys jetzt den Endpunkt (z. B.
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), nimmt Cloud Service Mesh das Update auf teilt sie es mit seinen Kunden.
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 z. B. mithilfe eines internen Application Load Balancers ein Ingress-Gateway, verteilt Anfragen an eine Sammlung von Kubernetes-Diensten in einem Cluster. 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 Cloud Service Mesh-Mesh konfigurieren, um auf Dienste zuzugreifen innerhalb des Perimeters durch das Gateway.
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. Anschließend können Sie diesen Dienst Cloud Service Mesh, damit Mesh-Clients wie Envoy- und gRPC-Clients und selbstverwaltete Gateways wie Apigee können diese Dienste aufrufen.
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.
Weitere domainübergreifende Beispiele
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. Ich Registrieren Sie das Gateway als Dienst in Service Directory und verwenden Sie dann Gateway mit Cloud Service Mesh, wie in diesem Dokument beschrieben.
Richtlinien anwenden, wenn auf Dienste zugegriffen wird
Cloud Service Mesh unterstützt Funktionen wie die erweiterte Traffic-Verwaltung, können mithilfe von Richtlinien konfiguriert werden. 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 ein Cloud Service Mesh binden Back-End-Dienst können Sie diese Richtlinientypen in Cloud Service Mesh 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
users werden an den Dienst audit gespiegelt (zum Vergrößern klicken)Unterstützung für Cloud Service Mesh und bestehende Clients
Auch wenn das Cloud Service Mesh in Ihrer Organisation bereitgestellt ist, die nicht Cloud Service Mesh nutzen. 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 ein Cloud Service Mesh binden Back-End-Dienst werden die Clients von Cloud Service Mesh automatisch aktualisiert, Informationen zu diesem Dienst. Ihre Clients, die Cloud Service Mesh nicht verwenden Dienstinformationen in Service Directory nachzuschlagen und zu verwenden.
Beschränkungen
Cloud Service Mesh unterstützt keine FQDN-NEGs (INTERNET_FQDN_PORT NEGs) in der
Service Directory-Integration
Nächste Schritte
- Weitere Informationen zum Einrichten der Integration
- Informationen zur Beobachtbarkeit mit dieser Integration finden Sie unter Beobachtbarkeit und Fehlerbehebung mit Service Directory.