Diensterkennung
Traffic Director bietet Dienst- und Endpunkterkennung. Mit diesen Features können Sie die VM-Instanzen und Containerinstanzen gruppieren, die Ihren Code als Endpunkte Ihrer Dienste ausführen.
Traffic Director überwacht diese Dienste, um aktuelle Informationen an seine Clients weiterzugeben. Wenn eine Ihrer Anwendungen ihren Traffic Director-Client (z. B. einen Envoy-Sidecar-Proxy) zum Senden einer Anfrage verwendet, profitiert sie somit von aktuellen Informationen zu Ihren Diensten.
Im Kontext von Traffic Director 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 Traffic Director-Client ist ein Envoy- oder gRPC- oder ein anderer xDS-Client, der mit Traffic Director verbunden und Teil der Datenebene ist.
In der Datenebene führt Envoy oder gRPC folgende Schritte aus:
- Er prüft eine Anfrage und ordnet sie einem Back-End-Dienst zu, einer Ressource, die Sie während der Bereitstellung konfigurieren.
- Nachdem die Anfrage abgeglichen wurde, wählt Envoy oder gRPC ein Back-End oder Endpunkt aus und leitet die Anfrage an dieses Back-End oder Endpunkt weiter.
Diensterkennung
Traffic Director bietet Diensterkennung. Wenn Sie Traffic Director konfigurieren, 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 Traffic Director-Client verarbeitet wird) mit einem bestimmten Dienst abgeglichen wird. Wenn ein Traffic Director-Client eine Anfrage verarbeitet, die einer Regel entspricht, kann er den Dienst auswählen, 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 Traffic Director 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 Routing-Regelzuordnung konfiguriert, die eine Weiterleitungsregel (mit Beispiel-IP
0.0.0.0
und -Port80
), einen Ziel-Proxy und eine URL-Zuordnung (mit Beispiel-Hostnamepayments.example.com
, der auf den Dienstpayments
verweist) enthält.
Wenn Ihre Anwendung (auf der VM) bei dieser Konfiguration eine HTTP-Anfrage an payments.example.com
an Port 80
sendet, weiß der Traffic Director-Client, dass dies eine Anfrage für den Dienst payments
ist.
Wenn Sie Traffic Director mit proxylosen gRPC-Diensten verwenden, funktioniert die Diensterkennung ähnlich. Eine gRPC-Bibliothek, die als Traffic Director-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
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. Traffic Director überwacht diese MIGs und NEGs, um zu wissen, wann Instanzen und Endpunkte erstellt und entfernt werden.
Traffic Director 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.
Im obigen Beispiel gibt Traffic Director die beiden fehlerfreien Endpunkte in MIG-1 und drei fehlerfreie Endpunkte in MIG-2 für den Dienst shopping-cart
zurück. Neben dem Hinzufügen von Endpunkten zu MIGs oder NEGs und dem Einrichten von Traffic Director benötigen Sie keine zusätzliche Konfiguration, um die Diensterkennung mit Traffic Director zu aktivieren.
Abfangen von Sidecar-Proxy-Traffic in Traffic Director
Traffic Director unterstützt das Sidecar-Proxy-Modell. Bei diesem Modell fängt iptables
Traffic ab, der von einer Anwendung an ihr Ziel gesendet wird. Der Traffic wird dann an den Sidecar-Proxy des Hosts weitergeleitet, auf dem die Anwendung ausgeführt wird. Der Sidecar-Proxy entscheidet, wie der Traffic verteilt wird, und sendet den Traffic an sein Ziel.
Im folgenden Diagramm, das davon ausgeht, dass Traffic Director richtig konfiguriert ist, ist Envoy der Sidecar-Proxy. Der Sidecar-Proxy wird auf demselben Host wie die Anwendung ausgeführt.
Ein Beispieldienst mit dem Namen Web
wird auf der virtuellen IP-Adresse (VIP) 10.0.0.1:80
konfiguriert, wo er von Traffic Director gefunden und mit einem Load-Balancing versehen werden kann.
Traffic Director erkennt die Konfiguration über die Konfiguration der Weiterleitungsregel, die die VIP und den Port bereitstellt. Die Back-Ends für den Dienst Web
sind konfiguriert und funktionieren, befinden sich jedoch außerhalb des Compute Engine-VM-Hosts im Diagramm.
Traffic Director entscheidet, dass das optimale Back-End für den Traffic zum Dienst Web
vom Host 192.168.0.1:80
ist.
Der Traffic-Fluss im Diagramm sieht so aus:
- Die Anwendung sendet Traffic an den Dienst
Web
, der zur IP-Adresse10.0.0.1:80
aufgelöst wird. - Der Netfilter auf dem Host ist so konfiguriert, dass der an
10.0.0.1:80
gerichtete Traffic an10.0.0.1:15001
weitergeleitet wird. - Der Traffic wird zu
127.0.0.1:15001
weitergeleitet, dem Abfangport des Envoy-Proxys. - Der Envoy-Proxy-Abfang-Listener auf
127.0.0.1:15001
empfängt den Traffic und führt eine Suche für das ursprüngliche Ziel der Anfrage (10.0.0.1:80
) durch. Die Suche führt dazu, dass192.168.0.1:8080
wie von Traffic Director programmiert als optimales Back-End ausgewählt wird. - Envoy stellt eine Verbindung über das Netzwerk mit
192.168.0.1:8080
her und leitet HTTP-Traffic zwischen der Anwendung und diesem Backend weiter, bis die Verbindung beendet wird.
Optionen zum Abfangen von Traffic mit automatischer Envoy-Bereitstellung
Wenn Sie die automatische Envoy-Bereitstellung mit VMs verwendet haben, bietet Traffic Director zusätzliche Optionen zum Abfangen von Traffic. Diese Optionen bieten folgende Möglichkeiten:
- Gesamten Traffic abfangen
- Bestimmte Ports, Portbereiche, IP-Adressen oder CIDR-Bereiche ausschließen
Wenn Sie die Mesh
- und Gateway
-Ressourcen der neuen Service Routing API verwenden, wird der gesamte Traffic automatisch abgefangen.
Weitere Informationen finden Sie unter Optionen für die Einrichtung einer Compute Engine-VM mit automatischer Envoy-Bereitstellung.
Nächste Schritte
- Informationen dazu, wie Traffic Director globales Load-Balancing für Ihre internen Mikrodienste mit Sidecar-Proxys bereitstellt, finden Sie unter Load-Balancing für Traffic Director.
- Weitere Informationen zu Traffic Director finden Sie in der Übersicht zu Traffic Director.