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:

  1. Er prüft eine Anfrage und ordnet sie einem Back-End-Dienst zu, einer Ressource, die Sie während der Bereitstellung konfigurieren.
  2. 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 Ihren payments-Dienst ausführen.
  • Sie haben eine Routing-Regelzuordnung konfiguriert, die eine Weiterleitungsregel (mit Beispiel-IP 0.0.0.0 und -Port 80), einen Ziel-Proxy und eine URL-Zuordnung (mit Beispiel-Hostname payments.example.com, der auf den Dienst payments 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.

Traffic Director-Hostnetzwerk
Traffic Director-Hostnetzwerk (zum Vergrößern klicken)

Der Traffic-Fluss im Diagramm sieht so aus:

  1. Die Anwendung sendet Traffic an den Dienst Web, der zur IP-Adresse 10.0.0.1:80 aufgelöst wird.
  2. Der Netfilter auf dem Host ist so konfiguriert, dass der an 10.0.0.1:80 gerichtete Traffic an 10.0.0.1:15001 weitergeleitet wird.
  3. Der Traffic wird zu 127.0.0.1:15001 weitergeleitet, dem Abfangport des Envoy-Proxys.
  4. 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, dass 192.168.0.1:8080 wie von Traffic Director programmiert als optimales Back-End ausgewählt wird.
  5. 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