Diensterkennung
Cloud Service Mesh bietet Dienst- und Endpunkterkennung. Mit diesen Funktionen können Sie die VM-Instanzen und Containerinstanzen gruppieren, die Ihren Code als Endpunkte Ihrer Dienste ausführen.
Cloud Service Mesh überwacht diese Dienste, damit sie gemeinsam Aktuelle Informationen zur Systemdiagnose mit seiner Kundschaft zu teilen. Wenn eine Ihrer Anwendungen Cloud Service Mesh-Client (z. B. ein Envoy-Sidecar-Proxy oder ein Proxylose gRPC-Anwendung) zum Senden einer Anfrage Informationen über Ihre Dienstleistungen.
Im Kontext von Cloud Service Mesh ist ein Client ein Anwendungscode. die auf einer VM oder in einem Container ausgeführt wird, der Anfragen zum Senden an einen Server formuliert. A server ist der Anwendungscode, der solche Anfragen empfängt. Ein Cloud Service Mesh-Client ist ein Envoy-, gRPC- oder anderer xDS-Client. das mit dem 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 Back-End-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 Back-End oder einen Endpunkt aus und leitet die Anfrage an dieses Back-End oder diesen Endpunkt weiter.
Diensterkennung
Cloud Service Mesh bietet Diensterkennung. Beim Konfigurieren Cloud Service Mesh erstellen Sie Back-End-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 wählen Sie den Dienst aus, der die Anfrage erhalten soll.
Beispiel:
- Sie haben eine VM, auf der Ihre Anwendung ausgeführt wird. 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
payments
konfiguriert. 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-Netzwerk namenssidecar-mesh
definiert. - Sie haben eine
Route
-Ressource konfiguriert, die Traffic-Ziele für den Back-End-Dienstpayments
und den Hostnamenhelloworld-gce
definiert.
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, ähnlich funktioniert. Eine gRPC-Bibliothek, die als Cloud Service Mesh-Client fungiert, ruft 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
Mit der Diensterkennung können sich Kunden über Ihre Dienste informieren. 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 Back-Ends für diesen Dienst an. Diese Back-Ends sind entweder VMs in verwalteten Instanzgruppen (MIGs) oder Container in NEGs. Cloud Service Mesh überwacht diese MIGs und NEGs, um zu wissen, 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 brauchen Sie keine zusätzliche Konfiguration, um die Diensterkennung mit Cloud Service Mesh.
Abfangen von Sidecar-Proxy-Traffic in Cloud Service Mesh
Cloud Service Mesh unterstützt das Sidecar-Proxy-Modell. Wenn bei diesem Modell ein die Anwendung Traffic an sein Ziel sendet, der Traffic abgefangen wird und an einen Port im Sidecar-Proxy 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 Service Routing APIs ist das Abfangen von Traffic werden automatisch verwaltet.
Nächste Schritte
- Hier erfahren Sie, wie Cloud Service Mesh globales Load-Balancing für Ihre interne Mikrodienste mit Sidecar-Proxys, siehe Cloud Service Mesh-Load-Balancing
- Weitere Informationen zum Cloud Service Mesh finden Sie in der Cloud Service Mesh – Übersicht