Erweiterte Trafficverwaltung

Traffic Director bietet erweiterte Funktionen zur Trafficverwaltung, mit denen Sie besser steuern können, wie Traffic verarbeitet wird. Traffic Director unterstützt folgende Anwendungsfälle:

  • Detaillierte Weiterleitung von Anfragen an einen oder mehrere Dienste
  • Anfrage- und antwortbasierte Aktionen wie Weiterleitungen und Headertransformationen
  • Optimierte Traffic-Verteilung auf den Back-Ends eines Dienstes, um das Load-Balancing zu optimieren

Mit diesen erweiterten Trafficverwaltungsfunktionen können Sie Ihre Verfügbarkeits- und Leistungsziele erreichen. Einer der Vorteile von Traffic Director für diese Anwendungsfälle ist, dass Sie die Verwaltung des Traffics aktualisieren können, ohne den Anwendungscode ändern zu müssen.

Fallbeispiele

Die erweiterte Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Weitere Beispiele einschließlich Beispielcode finden Sie in den Anleitungen Erweiterte Trafficverwaltung konfigurieren und VM-basierte proxylose gRPC-Dienste mit erweiterter Trafficverwaltung einrichten.

Detailliertes Traffic-Routing für die Personalisierung

Sie können Traffic anhand der Parameter der Anfrage an einen Dienst weiterleiten. Beispielsweise können Sie damit Nutzern ein personalisiertes Erlebnis bieten. Im folgenden Diagramm konfiguriert Traffic Director Ihr Service Mesh so, dass Anfragen mit dem Header user-agent:Android an den Android-Dienst statt an den generischen Dienst gesendet werden.

Routing anhand des Headers
Routing anhand des Headers user-agent, für den Android angegeben ist (zum Vergrößern klicken)

Gewichtete Trafficaufteilung für sicherere Bereitstellungen

Die Bereitstellung einer neuen Version eines bestehenden Produktionsdienstes birgt in der Regel ein gewisses Risiko. Auch wenn die Tests in einer Testumgebung erfolgreich sind, möchten Sie unter Umständen nicht sofort alle Nutzer an die neue Version weiterleiten.

Mit Traffic Director können Sie gewichtete Trafficaufteilungen definieren, um den Traffic auf mehrere Dienste zu verteilen. Sie können beispielsweise 1 % des Traffics an die neue Version Ihres Dienstes senden, beobachten, ob alles funktioniert, und dann den Anteil des Traffics zum neuen Dienst nach und nach erhöhen.

Gewichtete Trafficaufteilung für Traffic Director (zum Vergrößern klicken)
Gewichtete Trafficaufteilung für Traffic Director (zum Vergrößern klicken)

Trafficspiegelung für das Debugging

Wenn Sie ein Problem beheben möchten, kann es hilfreich sein, Kopien des Produktionstraffics an einen Debugging-Dienst zu senden. Mit Traffic Director können Sie Richtlinien für die Anfragespiegelung einrichten, sodass Anfragen an einen bestimmten Dienst gesendet werden und Kopien dieser Anfragen an einen anderen.

Trafficspiegelung für Traffic Director (zum Vergrößern klicken)
Trafficspiegelung für Traffic Director (zum Vergrößern klicken)

Optimiertes Load-Balancing für bessere Leistung

Je nach den Eigenschaften Ihrer Anwendung stellen Sie möglicherweise fest, dass Sie die Leistung und Verfügbarkeit verbessern können, wenn Sie die Verteilung des Traffics auf die Back-Ends eines Dienstes optimieren. Mit Traffic Director können Sie erweiterte Load-Balancing-Algorithmen anwenden, um den Traffic entsprechend Ihren Anforderungen zu verteilen.

Das folgende Diagramm zeigt im Gegensatz zu vorherigen sowohl einen Ziel-Back-End-Dienst (Produktion) als auch die Back-Ends für diesen Back-End-Dienst (virtuelle Maschine 1, virtuelle Maschine 2, virtuelle Maschine 3). Mit der erweiterten Trafficverwaltung können Sie festlegen, wie ein Ziel-Back-End-Dienst ausgewählt wird, und wie der Traffic zwischen den Back-Ends für diesen Zieldienst verteilt wird.

Load-Balancing für Traffic Director (zum Vergrößern klicken)
Load-Balancing für Traffic Director (zum Vergrößern klicken)

Funktionsweise der erweiterten Trafficverwaltung

Sie konfigurieren die erweiterte Trafficverwaltung mithilfe der Routingregelzuordnung und Back-End-Dienstressourcen, die Sie bei der Einrichtung von Traffic Director verwenden. Traffic Director konfiguriert wiederum Ihre Envoy-Proxys und proxylose gRPC-Anwendungen, um die von Ihnen eingerichteten erweiterten Richtlinien zur Trafficverwaltung durchzusetzen.

Auf übergeordneter Ebene führen Sie diese Schritte aus:

  1. Konfigurieren Sie die Routingregelzuordnung so, dass sie anhand der Eigenschaften der ausgehenden Anfrage Folgendes ausführt:

    1. Wählen Sie den Back-End-Dienst aus, an den Anfragen weitergeleitet werden sollen.

    2. Führen Sie ggf. weitere Aktionen aus.

  2. Konfigurieren Sie den Dienst (Back-End-Dienst), um zu steuern, wie Traffic nach der Auswahl eines Zieldienstes an Back-Ends und Endpunkte verteilt wird.

Trafficrouting und -aktionen

In Traffic Director bezieht sich die Routingregelzuordnung auf die Kombination aus Weiterleitungsregel, Zielproxy und URL-Zuordnungsressourcen. Alle erweiterten Trafficverwaltungsfunktionen in Verbindung mit Routing und Aktionen werden über die URL-Zuordnung konfiguriert.

Sie können in der Routingregelzuordnung die folgenden erweiterten Trafficverwaltungsfunktionen einrichten.

Anfragen verarbeiten

Wenn ein Client eine Anfrage sendet, wird sie so verarbeitet:

  1. Die Anfrage wird einer bestimmten Routingregelzuordnung zugeordnet. Dieser Abgleich erfolgt so:
    1. Wenn Sie Envoy verwenden:
      1. Die Ziel-IP-Adresse und der Zielport der Anfrage werden mit der IP-Adresse und dem Port der Weiterleitungsregeln in allen Zuordnungsregeln verglichen. Es werden nur Routingregelzuordnungen mit Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED berücksichtigt.
      2. Die Weiterleitungsregel, die mit der Anfrage übereinstimmt, verweist auf einen HTTP- oder gRPC-Proxy, der wiederum auf eine URL-Zuordnung verweist. Diese URL-Zuordnung enthält Informationen, die für Routing und Aktionen verwendet werden.
    2. Wenn Sie proxylose gRPC-Dienste verwenden:
      1. Die IP-Adresse der Anfrage wird ignoriert, da Sie die IP-Adresse 0.0.0.0 nur verwenden können, wenn Sie eine Weiterleitungsregel erstellen, die auf einen Ziel-gRPC-Proxy verweist. Es werden nur Routingregelzuordnungen mit Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED berücksichtigt.
      2. Der Port im Ziel-URI (z. B. xds:///foo.myservice:8080) wird mit dem Port der Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED verglichen. Die IP-Adresse einer Weiterleitungsregel wird nicht verwendet.
      3. Die Weiterleitungsregel, die mit der Anfrage übereinstimmt, verweist auf einen Ziel-gRPC-Proxy, der wiederum auf eine URL-Zuordnung verweist. Diese URL-Zuordnung enthält Informationen, die für Routing und Aktionen verwendet werden.
  2. Wenn die entsprechende URL-Zuordnung festgelegt ist, wird die URL-Zuordnung ausgewertet, um den Ziel-Back-End-Dienst zu bestimmen und optional Aktionen anzuwenden.
  3. Nachdem der Ziel-Back-End-Dienst ausgewählt wurde, wird der Traffic anhand der Konfiguration in der Back-End-Dienstressource auf die Back-Ends oder Endpunkte für diesen Ziel-Back-End-Dienst verteilt.

Der zweite Schritt wird im folgenden Abschnitt Einfaches Routing nach Host und Pfad beschrieben. Der dritte Schritt wird unter Erweitertes Routing und erweiterte Aktionen beschrieben.

Einfaches Routing nach Host und Pfad

Traffic Director unterstützt ein vereinfachtes und ein komplexeres Routingschema. Erweiterte Routingschemas, einschließlich Aktionen, werden im nächsten Abschnitt Erweitertes Routing und erweiterte Aktionen beschrieben. Im einfachen Schema geben Sie einen Host und optional einen Pfad an. Der Host und der Pfad der Anfrage werden ausgewertet, um den Dienst zu bestimmen, an den eine Anfrage weitergeleitet werden soll.

  • Der Host der Anfrage ist der Domainname einer URL. Der Hostteil der URL http://example.com/video/ ist beispielsweise example.com.
  • Der Pfad der Anfrage ist der Teil der URL, der dem Hostnamen folgt. Beispiel: /video in http://example.com/video.
Einfache Weiterleitung nach Host und Pfad einrichten

Das einfache Routing nach Host und Pfad wird in der Routingregelzuordnung eingerichtet, die aus Folgendem besteht:

  • Globale Weiterleitungsregel
  • Ziel-HTTP-Proxy oder Ziel-gRPC-Proxy
  • Eine URL-Zuordnung

Der Großteil der Konfiguration erfolgt in der URL-Zuordnung. Nachdem Sie die erste Routingregelzuordnung erstellt haben, müssen Sie meist nur den Teil der URL-Zuordnung der Routingregelzuordnung ändern. In diesem Diagramm haben die Pfadregeln ähnliche Aktionen wie im nächsten Diagramm.

Routing anhand von Host- und Pfadressourcen (zum Vergrößern klicken)
Routing anhand von Host- und Pfadressourcen (zum Vergrößern klicken)

Am einfachsten ist eine Standardregel, in der Sie nur eine Platzhalter-Hostregel (*) und ein Tool zum Abgleich von Pfaden mit einem Standarddienst angeben. Nachdem Sie die Standardregel erstellt haben, können Sie zusätzliche Regeln hinzufügen, mit denen verschiedene Hosts und Pfade angegeben werden. Ausgehende Anfragen werden folgendermaßen ausgewertet:

Wenn der Host einer Anfrage (z. B. example.com) mit einer Hostregel übereinstimmt:

  1. Das Tool zum Abgleich von Pfaden wird als Nächstes ausgewertet.
  2. Jedes Tool zum Abgleich von Pfaden enthält eine oder mehrere Pfadregeln, die hinsichtlich des Anfragepfads ausgewertet werden.
  3. Wird eine Übereinstimmung gefunden, wird die Anfrage an den in der Pfadregel angegebenen Dienst weitergeleitet.
  4. Jedes Tool zum Abgleich von Pfaden enthält einen Standarddienst, an den Anfragen weitergeleitet werden, wenn die Hostregel aber keine Pfadregeln übereinstimmen.

Stimmt die Anfrage mit keiner der von Ihnen angegebenen Hostregeln überein, wird sie an den in der Standardregel angegebenen Dienst weitergeleitet.

Weitere Informationen zu den Feldern einer URL-Zuordnungsressource und ihrer Funktionsweise finden Sie auf der Seite urlMaps REST API.

Erweitertes Routing und erweiterte Aktionen

Wenn Sie nicht nur eine Anfrage weiterleiten möchten, die auf dem Host und dem Pfad der Anfrage basiert, können Sie auch erweiterte Regeln einrichten, um Anfragen weiterzuleiten und Aktionen auszuführen.

Erweitertes Routing (zum Vergrößern klicken)
Erweitertes Routing (zum Vergrößern klicken)

Auf übergeordneter Ebene funktionieren erweitertes Routing und erweiterte Aktionen so:

  1. Wie bei einfachem Routing wird der Host der Anfrage mit den Hostregeln verglichen, die Sie in der URL-Zuordnung konfigurieren. Wenn der Host einer Anfrage mit einer Hostregel übereinstimmt, wird das Tool zum Abgleich von Pfaden der Hostregel ausgewertet.
  2. Es enthält eine oder mehrere Routingregeln, die anhand der Anfrage ausgewertet werden.
    1. Diese Routingregeln werden in der Reihenfolge ihrer Priorität ausgewertet. Dazu werden die Anfrageattribute (Host-, Pfad-, Header- und Abfrageparameter) nach bestimmten Abgleichsbedingungen abgeglichen, z. B. nach der Präfix-Abgleichsregel.
  3. Nachdem eine Routingregel ausgewählt wurde, können Aktionen angewendet werden. Die Standardaktion besteht darin, die Anfrage an einen Zieldienst weiterzuleiten. Sie können aber auch andere Aktionen festlegen.
Erweitertes Routing

Das erweiterte Routing ähnelt dem oben beschriebenen einfachen Routing, mit der Ausnahme, dass Sie die Priorität von Regeln und zusätzliche Abgleichsbedingungen wie unten beschrieben festlegen können.

Beim erweiterten Routing müssen Sie für jede Regel eine eindeutige Priorität angeben. Diese bestimmt die Reihenfolge, in der Routingregeln ausgewertet werden. Dabei haben Werte mit niedrigerer Priorität Vorrang vor höheren. Sobald eine Anfrage mit einer Regel übereinstimmt, wird die Regel angewendet und andere Regeln werden ignoriert.

Das erweiterte Routing unterstützt auch zusätzliche Abgleichsbedingungen. Sie können beispielsweise festlegen, dass eine Regel mit dem Header einer Anfrage übereinstimmt, wenn der Name des Headers genau oder nur teilweise übereinstimmt, z. B. anhand eines Präfixes oder Suffixes. Dabei kann der Name des Headers mit einem regulären Ausdruck verglichen oder können andere Kriterien herangezogen werden. Beispielsweise kann geprüft werden, ob ein Header vorhanden ist.

Durch die Kombination von Host-, Pfad-, Header- und Abfrageparametern mit Prioritäten und Abgleichsbedingungen können Sie besonders ausdrucksstarke Regeln erstellen, die genau den Anforderungen Ihrer Trafficverwaltung entsprechen.

HTTP-Hosts im Vergleich zu gRPC-Hosts

Wenn Sie eine HTTP-basierte Anwendung schreiben, ist der Host der Domainname in der URL, die von der Anwendung aufgerufen wird. Der Hostteil der URL http://example.com/video/ ist beispielsweise example.com.

Wenn Sie eine gRPC-basierte Anwendung schreiben, ist der Host der Name, den ein Client im Kanal-URI verwendet, um eine Verbindung zu einem bestimmten Dienst herzustellen. Der Hostteil des Kanal-URI xds:///example.com ist beispielsweise example.com.

HTTP-Pfade im Vergleich zu gRPC-Pfaden

Wenn Sie eine HTTP-basierte Anwendung schreiben, ist der Pfad der Teil der URL, der auf den Hostnamen folgt, z. B. /video in http://example.com/video.

Wenn Sie eine gRPC-basierte Anwendung schreiben, befindet sich der Pfad im Header :path der HTTP/2-Anfrage und sieht so aus: /SERVICE_NAME/METHOD_NAME/. Wenn Sie beispielsweise die Methode Download für den gRPC-Dienst Example aufrufen, sieht der Inhalt des Headers :path so aus: /Example/Download.

Andere gRPC-Header (Metadaten)

gRPC unterstützt das Senden von Metadaten zwischen dem gRPC-Client und dem gRPC-Server, um zusätzliche Informationen zu einem RPC-Aufruf bereitzustellen. Diese Metadaten liegen in Form von Schlüssel/Wert-Paaren vor, die als Header in der HTTP/2-Anfrage bereitgestellt werden.

Aktionen

Mit Traffic Director können Sie Aktionen festlegen, die von Envoy-Proxys oder proxylosen gRPC-Anwendungen übernommen werden, wenn eine Anfrage verarbeitet wird. Die folgenden Aktionen können mit Traffic Director konfiguriert werden.

Aktion (API-Feldname) Beschreibung
Weiterleitungen (urlRedirect) Gibt einen konfigurierbaren 3xx-Antwortcode zurück. Außerdem wird der Antwortheader Location mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.
URL-Umschreibungen (urlRewrite) Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Back-End-Dienst gesendet wird.
Headertransformationen (headerAction) Fügt Anfrageheader hinzu oder entfernt diese, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwortheader nach Empfang einer Antwort des Back-End-Dienstes hinzugefügt oder entfernt werden.
Trafficspiegelung (requestMirrorPolicy) Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst auf Fire-and-Forget-Basis wird hierbei eine identische Anfrage an den konfigurierten Spiegelungs-Back-End-Dienst gesendet. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, an den die gespiegelte Anfrage gesendet wird.

Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Back-End-Dienstes anstatt in der Produktionsversion zu beheben.
Gewichtete Trafficaufteilung (weightedBackendServices) Lässt zu, dass Traffic für eine übereinstimmende Regel an mehrere Back-End-Dienste verteilt wird, proportional zu einer benutzerdefinierten Gewichtung, die dem jeweiligen Back-End-Dienst zugewiesen ist.

Diese Funktion eignet sich zur Konfiguration abgestufter Bereitstellungen oder von A/B-Tests. Die Routingaktion könnte beispielsweise so konfiguriert werden, dass 99 % des Traffics an einen Dienst gesendet werden, der eine stabile Version einer Anwendung ausführt, während 1 % des Traffics an einen separaten Dienst mit einer neueren Version dieser Anwendung gesendet wird.
Wiederholungsversuche (retryPolicy) Wiederholungsversuche konfigurieren die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum erneuten Versuch sowie die maximal zulässige Anzahl an Wiederholungsversuchen.
Zeitlimit (timeout) Gibt das Zeitlimit für die ausgewählte Route an. Das Zeitlimit wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen.
Fehlerinjektion (faultInjectionPolicy) Kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Diese Funktion ist hilfreich, um die Ausfallsicherheit eines Dienstes gegenüber simulierten Störungen zu testen.
Sicherheitsrichtlinien (corsPolicy) Richtlinien für Cross-Origin Resource Sharing (CORS) verarbeiten die Einstellungen für die Erzwingung von CORS-Anfragen.

Weitere Informationen zu Aktionen und deren Funktionsweise finden Sie in der API-Referenz zu URL-Zuordnungen.

In jeder Routingregel können Sie eine der folgenden Routingaktionen angeben, die in der Google Cloud Console als "primäre Aktionen" bezeichnet werden:

  • Traffic an einen einzelnen Dienst weiterleiten (service)
  • Traffic auf mehrere Dienste aufteilen (weightedBackendServices)
  • Weiterleitungs-URLs (urlRedirect)

Darüber hinaus können Sie jede der zuvor erwähnten Routingaktionen mit mindestens einer der folgenden kombinieren, die in der Google Cloud Console als "Add-on-Aktionen" bezeichnet werden:

  • Anfrage-/Antwortheader bearbeiten (headerAction)
  • Trafficspiegelung (requestMirrorPolicy)
  • URL-Host/-Pfad umschreiben (urlRewrite)
  • Fehlgeschlagene Anfragen wiederholen (retryPolicy)
  • Zeitlimit festlegen (timeout)
  • Fehler in einem Prozentsatz des Traffics einführen (faultInjectionPolicy)
  • CORS-Richtlinie hinzufügen (corsPolicy)

Da Aktionen mit bestimmten Routingregeln verknüpft sind, kann der Envoy-Proxy oder die proxylose gRPC-Anwendung je nach Anfrage, die verarbeitet wird, verschiedene Aktionen ausführen.

Traffic auf die Back-Ends eines Dienstes verteilen

Wenn ein Client eine ausgehende Anfrage verarbeitet, wird wie unter Anfragenverarbeitung beschrieben zuerst ein Zieldienst ausgewählt. Anschließend muss er herausfinden, welches Back-End oder welcher Endpunkt die Anfrage erhalten soll.

Traffic auf Back-Ends verteilen (zum Vergrößern klicken)
Traffic zwischen Back-Ends verteilen (zum Vergrößern klicken)

Im obigen Diagramm wurde die Regel vereinfacht. Dies ist meist eine Hostregel, ein Tool zum Abgleich von Pfaden und mindestens eine Pfad- oder Routingregel. Der Zieldienst ist der Back-End-Dienst. Die Anfrage wird von Back-End 1 bis Back-End n empfangen und verarbeitet. Diese Back-Ends können beispielsweise virtuelle Compute Engine-Maschinen sein, die Ihren serverseitigen Anwendungscode hosten.

Standardmäßig sendet der Client, der die Anfrage verarbeitet, Anfragen an das nächstgelegene fehlerfreie Back-End mit Kapazität. Damit kein Back-End überlastet wird, erfolgt das Load-Balancing für nachfolgende Anfragen auf anderen Back-Ends des Zieldienstes. Hierfür wird der Load-Balancing-Algorithmus Round-Robin verwendet. In einigen Fällen kann es jedoch sinnvoller sein, dieses Verhalten genauer zu steuern.

Load-Balancing, Sitzungsaffinität und Schützen von Back-Ends

Sie können für jeden Dienst die folgenden Richtlinien zur Trafficverteilung festlegen.

Richtlinie (API-Feldname) Beschreibung
Load-Balancing-Modus (balancingMode) Sie legen fest, wie eine Netzwerk-Endpunktgruppe oder eine verwaltete Instanzgruppe ausgewählt wird, nachdem ein Zieldienst bestimmt wurde. Sie können den Load-Balancing-Modus so konfigurieren, dass die Last beispielsweise anhand gleichzeitiger Verbindungen, Anfragehäufigkeit und anderer Aspekte verteilt wird.
Load-Balancing-Richtlinie (localityLbPolicy) Legt den Load-Balancing-Algorithmus fest, der zum Verteilen des Traffics auf Back-Ends innerhalb einer Netzwerk-Endpunktgruppe oder einer verwalteten Instanzgruppe verwendet wird. Es stehen verschiedene Algorithmen wie etwa "Round Robin" und "Mindestanfrage" zur Auswahl, um die Leistung zu optimieren.
Sitzungsaffinität (sessionAffinity) Die Sitzungsaffinität versucht, Anfragen von einem bestimmten Client an dasselbe Back-End zu senden, solange das Back-End intakt ist und Kapazität hat. Traffic Director unterstützt vier verschiedene Optionen für die Sitzungsaffinität: Client-IP-Adresse, HTTP-cookiebasiert, HTTP-headerbasiert und Cookie-Affinität, die von Traffic Director selbst generiert wird.
Konsistenter Hash (consistentHash) Kann verwendet werden, um eine Soft-Sitzungsaffinität anhand von HTTP-Headern, Cookies oder anderen Attributen bereitzustellen.
Schutzschalter (circuitBreakers) Legt Obergrenzen für die Anzahl von Verbindungen und Anfragen pro Verbindung mit einem Back-End-Dienst fest.
Ausreißererkennung (outlierDetection) Sie geben die Kriterien an, um (1) fehlerhafte Back-Ends oder Endpunkte aus verwalteten Instanzgruppen oder Netzwerk-Endpunktgruppen zu entfernen und (2) ein Back-End oder einen Endpunkt wieder hinzuzufügen, wenn das System als fehlerfrei genug gilt, um Traffic zu empfangen. Mit der Systemdiagnose, die mit dem Dienst verknüpft ist, wird bestimmt, ob ein Back-End oder Endpunkt als fehlerfrei gilt.

Weitere Informationen zu den verschiedenen Optionen für die Trafficverteilung und ihre Funktionsweise finden Sie in der API-Referenz für Back-End-Dienste.

Konfiguration filtern

Eine der wichtigsten Aufgaben von Traffic Director besteht darin, die Konfiguration zu generieren und an verschiedene Traffic Director-Clients zu senden, z. B. an Envoy-Proxys und/oder gRPC-Anwendungen. Traffic Director steuert Ihr Service Mesh dadurch, dass die Konfiguration an seine Clients gesendet wird, damit sie wissen, was sie tun müssen. Traffic Director ist die Steuerungsebene.

Wenn Sie eine Konfiguration in Traffic Director erstellen oder aktualisieren, wird sie von Traffic Director in eine Sprache übersetzt, die seine Clients verstehen. Standardmäßig teilt Traffic Director diese Konfiguration mit allen Clients. In einigen Fällen möchten Sie vielleicht anpassen, welche Traffic Director-Clients eine bestimmte Konfiguration erhalten. Anders ausgedrückt, Sie filtern die Konfiguration nach bestimmten Clients.

Hierbei handelt es sich zwar um erweiterte Funktionen, doch die folgenden Beispiele veranschaulichen, wann die Filterkonfiguration für Sie nützlich sein könnte:

  • Ihre Organisation nutzt das Netzwerkmodell "Freigegebene VPCs" und mehrere Teams verwenden Traffic Director in verschiedenen Dienstprojekten. Wenn Sie Ihre Konfiguration von anderen Dienstprojekten isolieren möchten, können Sie die Konfiguration so filtern, dass bestimmte Traffic Director-Clients nur einen Teil der Konfiguration erhalten.
  • Sie haben eine sehr große Anzahl von Routingregeln und -diensten in Traffic Director konfiguriert und möchten verhindern, dass an jeden Traffic Director-Client eine riesige Menge von Konfigurationen gesendet wird. Ein Client, der eine ausgehende Anfrage mithilfe einer großen, komplexen Konfiguration auswerten muss, ist möglicherweise weniger leistungsfähig als ein Client, der lediglich eine Anfrage mit einer optimierten Konfiguration auswerten muss.

Die Konfigurationsfilterung basiert auf dem Konzept der Metadatenfilter:

  1. Wenn ein Traffic Director-Client eine Verbindung herstellt, übergibt er Informationen aus seiner Bootstrap-Datei an Traffic Director.
  2. Diese umfassen den Inhalt von Metadatenfeldern in Form von Schlüssel/Wert-Paaren, die Sie in der Bootstrap-Datei angeben, wenn Sie Ihre Envoy-Proxys und/oder gRPC-Anwendungen bereitstellen.
  3. Sie können Metadatenfilter in Weiterleitungsregeln und/oder Routingregeln einbinden, die Sie in der Routingregelzuordnung konfigurieren.
  4. Wenn Sie diesen Ressourcen Metadatenfilter hinzufügen, teilt Traffic Director die Konfiguration nur mit Clients, die Metadaten freigeben, die den Filterbedingungen für Metadaten entsprechen.

Sie können Metadatenfilter auf die Weiterleitungsregel anwenden. Dann werden die Routingregelzuordnung und die zugehörigen Dienste nur mit Traffic Director-Clients geteilt, die entsprechende Metadaten freigegeben.

Alternativ können Sie Metadatenfilter auf bestimmte Routingregeln anwenden. In diesem Fall teilt Traffic Director die spezifische Routingregel und die zugehörigen Dienste nur mit Traffic Director-Clients, die entsprechende Metadaten freigeben. Informationen zum Konfigurieren von Metadatenfiltern finden Sie unter Konfigurationsfilterung basierend auf MetadataFilter-Übereinstimmung einrichten.

Beschränkungen

Weitere Informationen