Service Discovery
Cloud Service Mesh bietet Dienst- und Endpunkterkennung. Mit diesen Features können Sie die VM- und Container-Instanzen gruppieren, die Ihren Code als Endpunkte Ihrer Dienste ausführen.
Cloud Service Mesh überwacht diese Dienste, um aktuelle Systemdiagnose-Informationen an seine Clients weiterzugeben. Wenn eine Ihrer Anwendungen ihren Cloud Service Mesh-Client (z. B. einen Envoy-Sidecar-Proxy oder eine proxylose gRPC-Anwendung) zum Senden einer Anfrage verwendet, profitiert sie somit von aktuellen Informationen zu Ihren Diensten.
Im Kontext von Cloud Service Mesh ist ein Client der Anwendungscode, der auf einer VM oder in einem Container ausgeführt wird und die Anfragen an einen Server ausgibt. Ein Server ist Anwendungscode, der solche Anfragen empfängt. Ein Cloud Service Mesh-Client ist ein Envoy- oder gRPC- oder ein anderer xDS-Client, der mit Cloud Service Mesh verbunden und Teil der Datenebene ist.
In der Datenebene führt Envoy oder gRPC folgende Schritte aus:
- Es prüft eine Anfrage und ordnet die Anfrage einem Backend-Dienst zu, einer Ressource, die Sie während der Bereitstellung konfigurieren.
- Nachdem die Anfrage abgeglichen wurde, wendet Envoy oder gRPC alle zuvor konfigurierten Traffic- oder Sicherheitsrichtlinien an, wählt ein Backend oder einen Endpunkt aus und leitet die Anfrage an dieses Backend oder diesen Endpunkt weiter.
Service Discovery
Cloud Service Mesh bietet Service Discovery. Wenn Sie Cloud Service Mesh konfigurieren, erstellen Sie Backend-Dienste. Sie definieren auch Routingregeln, die angeben, wie eine ausgehende Anfrage (eine Anfrage, die von Ihrem Anwendungscode gesendet und von einem Cloud Service Mesh-Client verarbeitet wird) mit einem bestimmten Dienst abgeglichen wird. Wenn ein Cloud Service Mesh-Client eine Anfrage verarbeitet, die einer Regel entspricht, kann er den Dienst auswählen, der die Anfrage erhalten soll.
Beispiel:
- Ihre Anwendung wird auf einer VM ausgeführt. Diese VM hat einen Envoy-Sidecar-Proxy, der mit Cloud Service Mesh verbunden ist und ausgehende Anfragen im Namen der Anwendung verarbeitet.
- Sie haben einen Backend-Dienst mit dem Namen
paymentskonfiguriert. Dieser Backend-Dienst hat zwei NEG-Backends (Netzwerk-Endpunktgruppe), die auf verschiedene Containerinstanzen verweisen, die den Code für Ihrenpayments-Dienst ausführen. - Sie haben eine
Mesh-Ressource konfiguriert, die ein Mesh namenssidecar-meshdefiniert. - Sie haben eine
Route-Ressource konfiguriert, die Traffic-Ziele für den Backend-Dienstpaymentsund den Hostnamenhelloworld-gcedefiniert.
Wenn Ihre Anwendung (auf der VM) bei dieser Konfiguration eine HTTP-Anfrage an payments.example.com sendet, weiß der Cloud Service Mesh-Client, dass dies eine Anfrage für den Dienst payments ist.
Wenn Sie Cloud Service Mesh mit proxylosen gRPC-Diensten verwenden, funktioniert Service Discovery ähnlich. Eine gRPC-Bibliothek, die als Cloud Service Mesh-Client fungiert, ruft jedoch nur Informationen zu den Diensten ab, für die Sie einen xDS-Resolver angeben. Standardmäßig ruft Envoy Informationen zu allen Diensten ab, die in dem VPC-Netzwerk (Virtual Private Cloud) konfiguriert sind, das in der Envoy-Bootstrap-Datei angegeben ist.
Endpunkterkennung
Service Discovery ermöglicht es Clients, Ihre Dienste zu kennen. Mit der Endpunkterkennung können sich Clients über die Instanzen informieren, auf denen Ihr Code ausgeführt wird.
Wenn Sie einen Dienst erstellen, geben Sie auch die Backends für diesen Dienst an. Diese Backends sind entweder VMs in verwalteten Instanzgruppen (MIGs) oder Container in NEGs. Cloud Service Mesh überwacht diese MIGs und NEGs, um zu erfahren, wann Instanzen und Endpunkte erstellt und entfernt werden.
Cloud Service Mesh sendet kontinuierlich aktuelle Informationen zu diesen Diensten mit seinen Clients. Anhand dieser Informationen können Clients verhindern, dass Traffic an Endpunkte gesendet wird, die nicht mehr existieren. Außerdem können Clients mehr über neue Endpunkte erfahren und die zusätzliche Kapazität nutzen, die diese Endpunkte bieten.
Neben dem Hinzufügen von Endpunkten zu MIGs oder NEGs und dem Einrichten von Cloud Service Mesh benötigen Sie keine weitere Konfiguration, um Service Discovery mit Cloud Service Mesh zu aktivieren.
Sidecar-Proxy-Traffic in Cloud Service Mesh abfangen
Cloud Service Mesh unterstützt das Sidecar-Proxy-Modell. Wenn bei diesem Modell Traffic von einer Anwendung an ihr Ziel gesendet wird, wird der Traffic abgefangen und an einen Port des Sidecar-Proxys auf dem Host weitergeleitet, auf dem die Anwendung ausgeführt wird. Der Sidecar-Proxy entscheidet, wie der Traffic verteilt wird, und sendet den Traffic an sein Ziel.
Mit Cloud Service Mesh und den Dienstrouting-APIs wird das Abfangen von Traffic automatisch durchgeführt.
Nächste Schritte
- Informationen dazu, wie Cloud Service Mesh globales Load-Balancing für Ihre internen Mikrodienste mit Sidecar-Proxys bereitstellt, finden Sie unter Load Balancing für Cloud Service Mesh.
- Weitere Informationen zu Cloud Service Mesh finden Sie in der Übersicht zu Cloud Service Mesh.