Traffic Director – Übersicht
Dieses Dokument richtet sich an Netzwerkadministratoren und Dienstinhaber, die sich mit Traffic Director und dessen Funktionen vertraut machen möchten.
Traffic Director ist eine verwaltete Steuerungsebene für das Anwendungsnetzwerk. Mit Traffic Director können Sie globale, hochverfügbare Dienste mit erweiterten Funktionen für das Anwendungsnetzwerk wie Trafficverwaltung und -beobachtbarkeit bereitstellen.
Bei wachsender Anzahl der Dienste und Mikrodienste in einer Bereitstellung ergeben sich in der Regel bestimmte Fragen in Bezug auf das Anwendungsnetzwerk:
- Wie kann ich die Stabilität meiner Dienste verbessern?
- Wie kann ich Traffic zu meinen Diensten ausführen und wie können die Dienste miteinander kommunizieren?
- Wie kann ich nachvollziehen, was passiert, wenn meine Dienste miteinander kommunizieren?
- Wie aktualisiere ich meine Dienste, ohne einen Ausfall zu riskieren?
- Wie verwalte ich die Infrastruktur, die meine Bereitstellung ermöglicht?
Traffic Director bietet eine Unterstützung für diese Fragestellungen in einem modernen, dienstbasierten Deployment. Traffic Director basiert auf der von Google Cloud verwalteten Infrastruktur, sodass Sie keine eigene Infrastruktur verwalten müssen. Sie können so Ihren Schwerpunkt auf die Bereitstellung des Anwendungscodes für Ihre geschäftlichen Problemstellungen legen, während Traffic Director die Komplexität der Anwendungsnetzwerke steuert.
Traffic Director für Service Mesh
Eine gängige Methode zur Behebung von Problemen des Anwendungsnetzwerks ist die Verwendung eines Service Mesh. Traffic Director unterstützt Service Mesh und viele andere Bereitstellungsmuster, die Ihren Anforderungen entsprechen.
In einem typischen Service Mesh gilt Folgendes:
- Sie stellen Ihre Dienste in einem Kubernetes-Cluster bereit.
- Jeder Pod der Dienste hat einen dedizierten Proxy (in der Regel Envoy), der als Sidecar-Proxy ausgeführt wird.
- Jeder Sidecar-Proxy kommuniziert mit der Netzwerkinfrastruktur (die Steuerungsebene), die in Ihrem Cluster installiert ist. Die Steuerungsebene gibt an die Sidecar-Proxys Informationen zu Diensten, Endpunkten und Richtlinien in Ihrem Service Mesh weiter.
- Wenn ein Pod eine Anfrage sendet oder empfängt, wird die Anfrage an den Sidecar-Proxy des Pods weitergeleitet. Der Sidecar-Proxy verarbeitet dann die Anfrage, z. B. durch Senden an das vorgesehene Ziel.
In den Diagrammen in diesem Dokument und anderen Traffic Director-Dokumenten stellen die sechsseitigen rosa Symbole die Proxys dar. Die Steuerungsebene ist mit jedem Proxy verbunden und stellt die Informationen bereit, die die Proxys zur Verarbeitung von Anfragen benötigen. Pfeile zwischen Feldern zeigen den Traffic-Fluss an. Mit dem Anwendungscode in Service A wird beispielsweise eine Anfrage gesendet. Der Proxy verarbeitet diese Anfrage und leitet sie an Service B weiter.
Mit diesem Modell lässt sich die Netzwerklogik aus Ihrem Anwendungscode herausnehmen. Sie können sich so auf die Unterstützung des Geschäftsbetriebs konzentrieren, während die Infrastruktur für das Deployment eines funktionsfähigen Anwendungsnetzwerks sorgt.
Spezielle Merkmale von Traffic Director
Traffic Director funktioniert ähnlich wie dieses Modell, unterscheidet sich aber in wichtigen Punkten. Der Hauptunterschied besteht darin, dass Traffic Director ein von Google Cloud verwalteter Dienst ist. Sie installieren ihn nicht, er wird nicht in Ihrem Cluster ausgeführt und muss nicht verwaltet werden.
Im folgenden Diagramm stellt Traffic Director die Steuerungsebene dar. In diesem Kubernetes-Cluster gibt es vier Dienste jeweils mit Sidecar-Proxys, die mit Traffic Director verbunden sind. Traffic Director stellt die Informationen bereit, die die Proxys zum Weiterleiten von Anfragen benötigen. Beispielsweise sendet der Anwendungscode auf einem Pod, der zu Service A gehört, eine Anfrage. Der neben diesem Pod ausgeführte Sidecar-Proxy verarbeitet die Anfrage und leitet sie an einen Pod weiter, der zu Service B gehört.
Jenseits eines Service Mesh
Traffic Director unterstützt mehr Deployment-Typen als ein typisches Service Mesh.
Multi-Cluster-Kubernetes
Mit Traffic Director funktioniert ein Anwendungsnetzwerk auch zwischen Kubernetes-Clustern. Im folgenden Diagramm stellt Traffic Director die Steuerungsebene für Kubernetes-Cluster in us-central1 und europe-west1 bereit.
Anfragen können zwischen den drei Diensten in us-central1, den beiden Diensten in europe-west1 und zwischen den Diensten in den beiden Clustern weitergeleitet werden.
Ihr Service Mesh kann sich über mehrere Kubernetes-Cluster in mehreren Google Cloud-Regionen erstrecken. Dienste in einem Cluster haben die Möglichkeit, mit Diensten in einem anderen Cluster zu kommunizieren. Sie können auch Dienste verwenden, die aus Pods in mehreren Clustern bestehen.
Mit dem auf Nachbarschaft ausgerichteten globalen Load-Balancing von Traffic Director werden Anfragen für Service B an den nächst liegenden Pod weitergeleitet, der die Anfrage verarbeiten kann. Außerdem profitieren Sie von einem nahtlosen Failover: Wenn ein Pod ausfällt, wird für die Anfrage automatisch ein Failover zu einem anderen Pod ausgeführt, der die Anfrage verarbeiten kann, auch wenn sich dieser Pod in einem anderen Kubernetes-Cluster befindet.
Virtuelle Maschinen
Kubernetes wird zwar immer beliebter, doch werden viele Arbeitslasten auf VM-Instanzen (virtuelle Maschinen) bereitgestellt. Traffic Director kann auch für diese Arbeitslasten als Steuerungsebene des Anwendungsnetzwerks dienen. Ihre VM-basierten Arbeitslasten lassen sich damit problemlos mit Ihren Kubernetes-basierten Arbeitslasten verknüpfen.
Im folgenden Diagramm gelangt der Traffic über den externen Application Load Balancer in Ihre Bereitstellung. Der Traffic wird zu Service A im Kubernetes-Cluster in asia-southeast1 und zu Service D auf einer VM in europe-west1 weitergeleitet.
Google bietet ein automatisiertes Verfahren zum Einrichten von VM-basierten Arbeitslasten mit Traffic Director. Sie fügen der Compute Engine-VM-Instanzvorlage lediglich ein Flag hinzu und Google kümmert sich um die Einrichtung der Infrastruktur. Zu dieser Einrichtung gehören auch die Installation und die Konfiguration der Proxys, die Funktionen für das Anwendungsnetzwerk bereitstellen.
Proxylose gRPC-Dienste
gRPC ist ein Open-Source-RPC-Framework mit großem Funktionsumfang, mit dem Sie leistungsstarke Mikrodienste programmieren können. Mit Traffic Director lassen sich auf einfache Weise Funktionen für das Anwendungsnetzwerk wie Diensterkennung, Load-Balancing und Trafficverwaltung in gRPC-Anwendungen einbinden. Weitere Informationen finden Sie unter Traffic Director und gRPC – proxylose Dienste für Ihr Service Mesh.
Im folgenden Diagramm wird dargestellt, wie gRPC-Anwendungen Traffic an Dienste in Kubernetes-Clustern in einer Region sowie an Dienste weiterleiten, die auf VMs in verschiedenen Regionen ausgeführt werden. Zwei der Dienste nutzen Sidecar-Proxys, alle anderen werden ohne Proxy ausgeführt.
Traffic Director unterstützt proxylose gRPC-Dienste. Diese Dienste verwenden eine aktuelle Version der Open-Source-gRPC-Bibliothek, die die xDS APIs unterstützt. Ihre gRPC-Anwendungen können über dieselben xDS APIs, die Envoy verwendet, eine Verbindung zu Traffic Director herstellen.
Nachdem Ihre Anwendungen verbunden wurden, stellt die gRPC-Bibliothek die Funktionalität des Anwendungsnetzwerks bereit, z. B. für Diensterkennung, Load-Balancing und Trafficverwaltung. Dies erfolgt nativ in gRPC, sodass keine Dienstproxys erforderlich sind. Sie werden deshalb als proxylose gRPC-Anwendungen bezeichnet.
Eingehender Traffic und Gateways
Für viele Anwendungsfälle muss Traffic von Clients verarbeitet werden, die nicht von Traffic Director konfiguriert sind. Beispielsweise kann der eingehende öffentliche Internettraffic zu Ihren Mikrodiensten weitergeleitet werden. Sie haben auch die Möglichkeit, einen Load-Balancer als Reverse-Proxy zu konfigurieren, der den Traffic von einem Client verarbeitet, bevor er an ein Ziel gesendet wird.
Im folgenden Diagramm aktiviert ein externer Application Load Balancer eingehenden Traffic für externe Clients, wobei Traffic an Dienste in einem Kubernetes-Cluster weitergeleitet wird. Ein interner Application Load Balancer leitet internen Traffic an den Dienst weiter, der auf der VM ausgeführt wird.
Traffic Director stellt in Verbindung mit Google Cloud Load Balancing eine verwaltete Umgebung für eingehenden Traffic bereit. Dazu richten Sie einfach einen externen oder internen Load-Balancer ein und konfigurieren diesen so, dass Traffic an die Mikrodienste gesendet wird. Im obigen Diagramm erreichen öffentliche Internetclients Ihre Dienste über den externen Application Load Balancer. Clients wie Mikrodienste, die sich in Ihrem VPC-Netzwerk (Virtual Private Cloud) befinden, verwenden einen internen Application Load Balancer, um Ihre Dienste zu erreichen.
Für einige Anwendungsfälle sollten Sie Traffic Director einrichten, um damit ein Gateway zu konfigurieren. Ein Gateway ist im Wesentlichen ein Reverse-Proxy, der in der Regel Envoy auf einer oder mehreren VMs ausführt, womit eingehende Anfragen überwacht, verarbeitet und an ein Ziel gesendet werden. Das Ziel kann sich in einer beliebigen Google Cloud-Region oder in einem GKE-Cluster (Google Kubernetes Engine) befinden. Es kann aber auch ein Ziel außerhalb von Google Cloud sein, das über Hybridkonnektivität in Google Cloud erreichbar ist. Weitere Informationen zur Verwendung eines Gateways finden Sie unter Eingehender Traffic für Ihr Mesh.
Im folgenden Diagramm wird dargestellt, wie eine VM in der Region europe-west1 einen Proxy ausführt, der als Gateway für drei Dienste dient, die keine Proxys ausführen. Traffic von einem externen und einem internen Application Load Balancer wird an das Gateway und dann an die drei Dienste weitergeleitet.
Mehrere Umgebungen
Ob Sie nun Dienste in Google Cloud, lokal und/oder in anderen Clouds bereitstellen: Die grundlegenden Problemstellungen für Anwendungsnetzwerke sind jeweils die gleichen. Wie wird Traffic an diese Dienste geleitet? Und wie kommunizieren diese Dienste miteinander?
Das folgende Diagramm zeigt, wie Traffic Director den Traffic von Diensten, die in Google Cloud ausgeführt werden, zu Service G in einer anderen öffentlichen Cloud und zu Service E sowie zu Service F in einem lokalen Rechenzentrum weiterleitet.
Service A, Service B und Service C verwenden Envoy als Sidecar-Proxy, während Service D ein proxyloser gRPC-Dienst ist.
Mit Traffic Director können Sie Anfragen an Ziele außerhalb von Google Cloud senden. Damit haben Sie die Möglichkeit, mithilfe von Cloud Interconnect oder Cloud VPN Traffic von Diensten innerhalb von Google Cloud privat an Dienste oder Gateways in anderen Umgebungen weiterzuleiten.
Traffic Director einrichten
Die Einrichtung von Traffic Director umfasst zwei Schritte. Nach Abschluss der Einrichtung wird das Anwendungsnetzwerk von der Infrastruktur verwaltet. Traffic Director sorgt dafür, dass Änderungen des Deployments immer aktuell übernommen werden.
Anwendungen bereitstellen
Als Erstes stellen Sie Ihren Anwendungscode für Container oder VMs bereit. Google bietet die Verfahren, mit denen Sie Ihren VM-Instanzen und Pods auf einfache Weise die Infrastruktur für ein Anwendungsnetzwerk (in der Regel Envoy-Proxys) hinzufügen können. Diese Infrastruktur ist so eingerichtet, dass sie mit Traffic Director kommuniziert und damit Informationen über Ihre Dienste erfasst.
Traffic Director konfigurieren
Als Nächstes konfigurieren Sie Ihre globalen Dienste und legen dabei fest, wie der Traffic verarbeitet werden soll. Sie können Traffic Director unter Verwendung der Google Cloud Console (für einige Features und Konfigurationen), der Google Cloud CLI, der Traffic Director API oder anderer Tools wie Terraform konfigurieren.
Nach Ausführung dieser Schritte lässt sich mit Traffic Director die Infrastruktur Ihres Anwendungsnetzwerks konfigurieren.
Infrastruktur verwaltet Anwendungsnetzwerke
Wenn eine Anwendung eine Anfrage an my-service sendet, wird die Anfrage von der Infrastruktur Ihres Anwendungsnetzwerks (z. B. von einem Envoy-Sidecar-Proxy) gemäß den Informationen von Traffic Director verarbeitet. Dadurch lässt sich eine Anfrage für my-service nahtlos an eine Anwendungsinstanz weiterleiten, die in der Lage ist, die Anfrage zu empfangen.
Monitoring und kontinuierliche Updates
Traffic Director überwacht die Anwendungsinstanzen, aus denen Ihre Dienste bestehen. So kann Traffic Director feststellen, ob ein Dienst fehlerfrei ausgeführt wird oder ob sich die Kapazität eines Dienstes geändert hat, z. B. wenn ein neuer Kubernetes-Pod erstellt wurde. Anhand dieser Informationen aktualisiert Traffic Director kontinuierlich die Infrastruktur Ihres Anwendungsnetzwerks.
Features
Die Features von Traffic Director bieten Ihren Mikrodiensten eine Funktionalität für Anwendungsnetzwerke. Im folgenden Abschnitt werden einige wichtige Features erläutert.
Vollständig verwaltete Steuerungsebene, Systemdiagnose und Load-Balancing
Sie möchten sich auf die Unterstützung des Geschäftsbetriebs konzentrieren und nicht die Infrastruktur verwalten müssen. Traffic Director ist eine vollständig verwaltete Lösung mit einem SLA für Verfügbarkeit. Sie müssen damit also keine eigene Infrastruktur installieren, konfigurieren oder aktualisieren. Dabei profitieren Sie von derselben Infrastruktur, die Google für Systemdiagnosen und globales Load-Balancing nutzt.
Open-Source-Produkte als Grundlage
Traffic Director nutzt die gleichen Steuerungsebenen-APIs (xDS), die beliebte Open-Source-Projekte wie Envoy und Istio verwenden. Informationen zu den unterstützten API-Versionen finden Sie unter APIs der xDS-Steuerungsebene.
Die Infrastruktur für Anwendungsnetzwerkfunktionen – je nach Anwendungsfall entweder Envoy oder gRPC – ist Open Source-basiert. Sie laufen also nicht Gefahr, den Beschränkungen einer firmeneigenen Infrastruktur ausgesetzt zu sein.
Skalieren
Von einmaligen Lösungen für Anwendungsnetzwerke bis zu umfangreichen Service Mesh-Deployments mit Tausenden von Diensten ist Traffic Director optimal für Ihre Skalierungsanforderungen ausgelegt.
Diensterkennung und Tracking von Endpunkten sowie von Back-Ends
Wenn Ihre Anwendung eine Anfrage an my-service sendet, verarbeitet die Infrastruktur die Anfrage nahtlos und sendet sie an das richtige Ziel. Ihre Anwendung benötigt dafür keine Informationen über IP-Adressen, Protokolle oder andere Netzwerkkomplexitäten.
Globales Load-Balancing und Failover
Traffic Director nutzt das globale Load-Balancing und die Systemdiagnose von Google, um den Traffic auf Basis des Client- und Back-End-Standorts, der Back-End-Nähe, des Zustands und der Kapazität optimal auszugleichen. Sie verbessern die Dienstverfügbarkeit, indem Sie für den Traffic ein automatisches Failover auf fehlerfreie Back-Ends mit Kapazität einrichten. Sie können das Load-Balancing anpassen, um den Traffic entsprechend Ihren Geschäftsanforderungen zu verteilen.
Trafficverwaltung
Mit erweiterter Trafficverwaltung einschließlich Routing- und Anfragebearbeitung (anhand von Hostname, Pfad, Headern, Cookies usw.) können Sie festlegen, wie Traffic zwischen Ihren Diensten geleitet wird. Außerdem haben Sie die Möglichkeit, Aktionen wie wiederholte Versuche, Weiterleitungen und gewichtete Trafficaufteilung für Canary-Deployments anzuwenden. Erweiterte Methoden wie Fehlerinjektion, Trafficspiegelung und Ausreißererkennung ermöglichen DevOps-Anwendungsfälle, mit denen die Ausfallsicherheit erhöht wird.
Beobachtbarkeit
Ihre Netzwerkinfrastruktur Ihrer Anwendung erfasst Telemetriedaten wie Messwerte, Logs und Traces, die zentral in der Google Cloud-Beobachtbarkeit zusammengefasst werden können. Nachdem diese Informationen gesammelt wurden, können Sie Einblicke gewinnen und Benachrichtigungen erstellen, damit Sie informiert werden, wenn etwas schief läuft.
VPC Service Controls
Mit VPC Service Controls können Sie die Sicherheit der Ressourcen und Dienste Ihrer Anwendung erhöhen. Sie können Projekte zu Dienstperimetern hinzufügen, die Ressourcen und Dienste (z. B. Traffic Director) vor Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben. Weitere Informationen zu VPC Service Controls finden Sie in der Übersicht zu VPC Service Controls.
Weitere Informationen zur Verwendung von Traffic Director mit VPC Service Controls finden Sie auf der Seite Unterstützte Produkte.
Nächste Schritte
So stellen Sie Traffic Director bereit:
- Verwenden Sie für Compute Engine mit VMs die Service Routing APIs.
- Verwenden Sie für Google Kubernetes Engine mit Pods die Gateway-APIs.
Informationen zu Anwendungsfällen und Architekturmustern für proxylose gRPC-Dienste finden Sie in der Proxylose gRPC-Dienste – Übersicht.
Informationen zur Handhabung der Trafficverwaltung finden Sie unter Erweiterte Trafficverwaltung – Übersicht.
In den folgenden Dokumenten erfahren Sie, wie Traffic Director Umgebungen außerhalb von Google Cloud unterstützt: