Traffic Director für Bereitstellungen in mehreren Umgebungen

Traffic Director unterstützt Umgebungen außerhalb von Google Cloud einschließlich lokaler Rechenzentren und anderer öffentlicher Clouds, die über Hybridkonnektivität erreichbar sind. Sie konfigurieren Traffic Director dafür so, dass Ihr Service Mesh Traffic an Endpunkte außerhalb von Google Cloud senden kann. Diese Endpunkte können lokale Load-Balancer, Serveranwendungen auf einer virtuellen Maschine in einer anderen Cloud oder beliebige andere Ziele sein, die über Hybridkonnektivität erreichbar sind und mit einer IP-Adresse und mit einem Port dargestellt werden können. Sie fügen dazu einfach einer Netzwerk-Endpunktgruppe (NEG) mit Hybridkonnektivität die IP-Adresse und den Port jedes Endpunkts hinzu.

Die Unterstützung von Traffic Director für lokale und Multi-Cloud-Dienste bietet folgende Vorteile:

  • Sie können Traffic global weiterleiten, auch an die Endpunkte lokaler und Multi-Cloud-Dienste.
  • Sie können die Features von Traffic Director und Service Mesh einschließlich Funktionen wie Service Discovery und erweiterte Trafficverwaltung für Dienste nutzen, die in Ihrer vorhandenen Infrastruktur außerhalb von Google Cloud ausgeführt werden.
  • Sie können die Traffic Director-Funktionen mit Cloud Load Balancing kombinieren, um Google Cloud-Netzwerkdienste in mehrere Umgebungen einzubinden.

Anwendungsfälle

Mit Traffic Director kann das Netzwerk zwischen VM- und containerbasierten Diensten in mehreren Umgebungen konfiguriert werden. Dazu gehören unter anderem:

  • Google Cloud
  • Lokale Rechenzentren
  • Andere öffentliche Clouds

Mesh-Traffic an einen lokalen Speicherort oder zu einer anderen Cloud weiterleiten

Der einfachste Anwendungsfall für dieses Feature ist das Trafficrouting. Ihre Anwendung führt dazu einen Traffic Director-Client aus, entweder Envoy-Proxy oder proxylose gRPC-Bibliothek. Traffic Director informiert den Client über Ihre Dienste und die Endpunkte der einzelnen Dienste.

Routing des Mesh-Traffics an einen lokalen Speicherort oder zu einer anderen Cloud (zum Vergrößern klicken)
Routing des Mesh-Traffics zu einem lokalen Speicherort oder zu einer anderen Cloud (zum Vergrößern klicken)

Wenn im obigen Diagramm Ihre Anwendung eine Anfrage an den on-prem-Dienst sendet, prüft der Traffic Director-Client die ausgehende Anfrage und aktualisiert ihr Ziel. Als Ziel wird ein Endpunkt festgelegt, der mit dem on-prem-Dienst (in diesem Fall 10.2.0.1) verknüpft ist. Die Anfrage wird dann über Cloud VPN oder Cloud Interconnect an das vorgesehene Ziel weitergeleitet.

Sie können Ihrem Dienst weitere Endpunkte hinzufügen. Aktualisieren Sie dafür einfach Traffic Director. Sie müssen keine Änderungen am Anwendungscode vornehmen.

Vorhandenen lokalen Dienst zu Google Cloud migrieren

Durch Senden von Traffic an einen Endpunkt außerhalb von Google Cloud können Sie Traffic an andere Umgebungen weiterleiten. Diese Funktion lässt sich mit der erweiterten Trafficverwaltung kombinieren, um Dienste zwischen Umgebungen sowie zwischen anderen Anwendungsfällen zu migrieren.

Von einem lokalen Speicherort zu Google Cloud migrieren (zum Vergrößern klicken)
Von einem lokalen Speicherort zu Google Cloud migrieren (zum Vergrößern klicken)

Das obige Diagramm erweitert das vorherige Muster. Anstatt Traffic Director so zu konfigurieren, dass der gesamte Traffic an den on-prem-Dienst gesendet wird, wird Traffic Director mithilfe der gewichteten Trafficaufteilung für die Aufteilung von Traffic auf zwei Dienste konfiguriert.

Bei der Trafficaufteilung können Sie mit dem Senden von 0 % des Traffics an den cloud-Dienst und von 100 % an den on-prem-Dienst beginnen. Anschließend erhöhen Sie bei Bedarf schrittweise den Anteil des an den cloud-Dienst gesendeten Traffics. Schließlich senden Sie 100 % des Traffics an den cloud-Dienst und deaktivieren den on-prem-Dienst.

Edge-Netzwerkdienste von Google Cloud für lokale und Multi-Cloud-Bereitstellungen

Diese Funktionalität kann auch mit den vorhandenen Netzwerklösungen von Google Cloud kombiniert werden. Google Cloud bietet eine breite Palette von Netzwerkdiensten, z. B. ein globales externes Load-Balancing mit Google Cloud Armor für den DDoS-Schutz, mit denen Sie jetzt in Verbindung mit Traffic Director neue Funktionen für Ihre lokalen oder Multi-Cloud-Dienste bereitstellen können. Diese lokalen oder Multi-Cloud-Dienste müssen dabei nicht über das öffentliche Internet verfügbar sein.

Bereitstellungen in mehreren Umgebungen (zum Vergrößern klicken)
Bereitstellungen in mehreren Umgebungen (zum Vergrößern klicken)

Im obigen Diagramm wird der Traffic von Clients im öffentlichen Internet von einem Google Cloud-Load-Balancer, z. B. von unserem globalen externen HTTP(S)-Load-Balancer, zum Google Cloud-Netzwerk weitergeleitet. Sie können dabei Edge-Netzwerkdienste anwenden, z. B. den Schutz vor DDoS-Angriffen mit Google Cloud Armor oder die Nutzerauthentifizierung mit Identity-Aware Proxy, wenn der Traffic den Load-Balancer erreicht. Weitere Informationen finden Sie unter Edge-Netzwerkdienste für Bereitstellungen in mehreren Umgebungen.

Nachdem Sie diese Dienste festgelegt haben, wird der Traffic in Google Cloud kurz unterbrochen. Dort leitet eine Anwendung oder ein eigenständiger Proxy (von Traffic Director konfiguriert) den Traffic über Cloud VPN oder Cloud Interconnect an Ihren lokalen Dienst weiter.

Architektur und Ressourcen

Dieser Abschnitt enthält Hintergrundinformationen zu den Google Cloud-Ressourcen, die zum Bereitstellen eines von Traffic Director verwalteten Service Mesh für lokale und Multi-Cloud-Umgebungen verwendet werden.

Google Cloud-Ressourcen

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die die Unterstützung von lokalen und Multi-Cloud-Diensten für Traffic Director ermöglichen. Beachten Sie, dass die Schlüsselressource die NEG und deren Netzwerkendpunkte sind. Alle anderen Ressourcen werden im Rahmen der Standardeinrichtung von Traffic Director konfiguriert.

Compute Engine-Ressourcen für lokale und Multi-Cloud-Dienste (zum Vergrößern klicken)
Compute Engine-Ressourcen für lokale und Multi-Cloud-Dienste (zum Vergrößern klicken)

Der Einfachheit halber sind Optionen wie die Verwendung mehrerer globaler Back-End-Dienste nicht im Diagramm dargestellt.

Beim Konfigurieren von Traffic Director erstellen Sie Dienste mithilfe der globalen API-Ressource für Back-End-Dienste. Ein Dienst ist im Prinzip ein logisches Konstrukt, das Folgendes kombiniert:

  1. Richtlinien, die angewendet werden sollen, wenn ein Client versucht, Traffic an den Dienst zu senden
  2. Ein oder mehrere Back-Ends oder Endpunkte, die den Traffic verarbeiten, der für den Dienst bestimmt ist

Die Konfiguration von lokalen und Multi-Cloud-Diensten entspricht grundsätzlich der anderer Dienste, die mit Traffic Director konfiguriert werden. Der Hauptunterschied besteht darin, dass Sie die Endpunkte dieser Dienste mithilfe einer Hybridkonnektivitäts-NEG konfigurieren. Dies sind NEGs, bei denen für den Netzwerkendpunkttyp der Wert non-gcp-private-ip-port festgelegt ist. Die Endpunkte, die Sie zu Hybridkonnektivitäts-NEGs hinzufügen, müssen gültige IP:port-Kombinationen sein, die von Ihren Clients erreicht werden können, z. B. über Hybridkonnektivität mit Cloud VPN oder Cloud Interconnect.

Die NEG hat einen Netzwerkendpunkttyp und jede NEG kann nur Netzwerkendpunkte eines Typs enthalten. Mit diesem Typ wird Folgendes festgelegt:

  • Das Ziel, an das Ihre Dienste Traffic senden können
  • Das Verhalten der Systemdiagnose

Beim Erstellen der NEG konfigurieren Sie diese so, dass Traffic an ein lokales oder Multi-Cloud-Ziel gesendet werden kann:

  • Legen Sie für den Netzwerkendpunkttyp non-gcp-private-ip-port fest. Dieser Wert stellt eine erreichbare IP-Adresse dar. Wenn dies eine lokale IP-Adresse oder die IP-Adresse eines anderen Cloud-Anbieters ist, muss sie von Google Cloud über Hybridkonnektivität erreichbar sein, etwa in Form der Konnektivität über Cloud VPN oder Cloud Interconnect.
  • Geben Sie eine Google Cloud-Zone an, mit der die geografische Entfernung zwischen Google Cloud und Ihrer lokalen oder Multi-Cloud-Umgebung minimiert wird. Wenn Sie beispielsweise einen Dienst in einer lokalen Umgebung in Frankfurt/Main hosten, legen Sie beim Erstellen der NEG die Google Cloud-Zone europe-west3-a fest.

Das Verhalten von Systemdiagnosen für Netzwerkendpunkte dieses Typs unterscheidet sich von Systemdiagnosen für andere Arten von Netzwerkendpunkten. Während andere Netzwerkendpunkttypen das zentrale System von Google Cloud verwenden, nutzen non-gcp-private-ip-port-Netzwerkendpunkte das Verfahren der verteilten Systemdiagnose von Envoy. Weitere Informationen dazu finden Sie unter Einschränkungen und weitere Aspekte.

Informationen zu Konnektivität und Netzwerken

  • Ihre Traffic Director-Clients wie z. B. Envoy-Proxys oder proxylose gRPC-Bibliotheken müssen eine Verbindung zu Traffic Director unter trafficdirector.googleapis.com:443 herstellen können. Wenn die Verbindung zur Traffic Director-Steuerungsebene getrennt ist, gilt Folgendes:
    • Für vorhandene Traffic Director-Clients kann dann keine Änderung der Konfiguration von Traffic Director übernommen werden. Sie funktionieren weiterhin gemäß ihrer aktuellen Konfiguration.
    • Neue Traffic Director-Clients können keine Verbindung zu Traffic Director herstellen. Das Service Mesh kann erst verwendet werden, wenn die Verbindung wiederhergestellt ist.
  • Wenn Sie Traffic zwischen Google Cloud und lokalen oder Multi-Cloud-Umgebungen senden möchten, müssen die Umgebungen über Hybridkonnektivität verbunden sein. Wir empfehlen dafür eine Verbindung mit Hochverfügbarkeit über Cloud Interconnect oder Cloud VPN.
  • Die IP-Adressen und IP-Adressbereiche für lokale, andere Cloud- und Google Cloud-Subnetze dürfen sich nicht überschneiden.

Einschränkungen und weitere Aspekte

Einstellen von proxyBind

Sie können den Wert von proxyBind nur festlegen und ändern, wenn Sie einen targetHttpProxy neu erstellen. Ein vorhandener targetHttpProxy lässt sich nicht aktualisieren.

Konnektivität und Unterbrechung der Konnektivität

Weitere Informationen zu Anforderungen und Einschränkungen von Verbindungen finden Sie unter Informationen zu Konnektivität und Netzwerken.

Gemischte Back-End-Typen

Ein Back-End-Dienst kann VM- oder NEG-Back-Ends enthalten. Wenn ein Back-End-Dienst NEG-Back-Ends enthält, müssen alle entsprechenden NEGs den gleichen Netzwerkendpunkttyp haben. Es sind keine Back-End-Dienste mit mehreren NEGs mit unterschiedlichen Endpunkttypen möglich.

Eine URL-Zuordnung kann Hostregeln enthalten, die in verschiedene Back-End-Dienste aufgelöst werden. So sind ein Back-End-Dienst mit ausschließlich Hybridkonnektivitäts-NEGs (mit lokalen Endpunkten) und ein Back-End-Dienst mit eigenständigen NEGs (mit GKE-Endpunkten) möglich. Die URL-Zuordnung kann Regeln enthalten (z. B. eine gewichtete Trafficaufteilung), die den Traffic auf alle diese Back-End-Dienste aufteilt.

NEG mit Endpunkten vom Typ non-gcp-private-ip-port mit Google Cloud-Back-Ends verwenden

Sie haben die Möglichkeit, einen Back-End-Dienst mit einer Hybridkonnektivitäts-NEG zu erstellen, die auf Back-Ends in Google Cloud verweist. Dieses Konzept wird allerdings nicht empfohlen. Für Hybridkonnektivitäts-NEGs haben zentrale Systemdiagnosen keinen Nutzen. Eine Beschreibung der zentralen Systemdiagnose und der verteilten Systemdiagnose finden Sie unter Systemdiagnose.

Endpunktregistrierung

Wenn Sie einer NEG einen Endpunkt hinzufügen möchten, müssen Sie die NEG aktualisieren. Dies kann entweder manuell geschehen oder mithilfe der REST APIs der Google Cloud-Netzwerk-Endpunktgruppe bzw. mit dem gcloud-Befehlszeilentool automatisiert werden. Wenn eine neue Instanz eines Dienstes gestartet wird, können Sie die Instanz mithilfe von Google Cloud APIs bei der von Ihnen konfigurierten NEG registrieren. Bei Verwendung von Compute Engine-MIGs oder GKE (in Google Cloud) wird die Endpunktregistrierung automatisch vom MIG- oder NEG-Controller ausgeführt.

Systemdiagnose

Das Verhalten von Systemdiagnosen unterscheidet sich vom Standardverhalten der zentralen Systemdiagnose, wenn Sie Hybridkonnektivitäts-NEGs verwenden:

  • Für Netzwerkendpunkte vom Typ gce-vm-ip-port erhält Traffic Director vom zentralen Systemdiagnosesystem von Google Cloud Informationen zum Endpunktstatus. Traffic Director stellt diese Informationen für Ihre Traffic Director-Clients bereit, sodass auf die möglicherweise kostenintensive Systemdiagnose auf Datenebene verzichtet werden kann.
  • Bei Netzwerkendpunkten vom Typ non-gcp-private-ip-port konfiguriert Traffic Director deren Clients so, dass Systemdiagnosen über die Datenebene verarbeitet werden. Envoy-Instanzen führen eigene Systemdiagnosen aus und nutzen eigene Verfahren, um das Senden von Anfragen an fehlerhafte Back-Ends zu unterbinden.
  • Da die Systemdiagnosen von der Datenebene verarbeitet werden, können Sie den Status einer Systemdiagnose nicht mit der Google Cloud Console, mit der API oder mit gcloud abrufen.

In der Praxis bedeutet die Verwendung von non-gcp-private-ip-port Folgendes:

  • Es werden nur HTTP- und TCP-Systemdiagnosen unterstützt.
  • Da Traffic Director-Clients die Systemdiagnosen verteilt ausführen, kann es vorkommen, dass der Netzwerktraffic aufgrund von Systemdiagnosen zunimmt. Die Zunahme hängt von der Anzahl der Traffic Director-Clients und der Anzahl der Endpunkte ab, die jeder Client für die Systemdiagnose benötigt. Beispiel:
    • Wenn Sie einer Hybridkonnektivitäts-NEG einen weiteren Endpunkt hinzufügen, führen vorhandene Traffic Director-Clients möglicherweise eine Systemdiagnose für die Endpunkte in Hybridkonnektivitäts-NEGs aus.
    • Wenn Sie Ihrem Service Mesh eine weitere Instanz hinzufügen, z. B. eine VM-Instanz, die Ihren Anwendungscode und einen Traffic Director-Client ausführt, führt die neue Instanz möglicherweise Systemdiagnosen für die Endpunkte in Hybridkonnektivitäts-NEGs aus.
    • Netzwerktraffic aufgrund von Systemdiagnosen steigt quadratisch (O(n^2)) an.

Virtual Private Cloud-Netzwerk

Ein Service Mesh lässt sich durch seinen VPC-Netzwerknamen eindeutig identifizieren. Für Traffic Director-Clients gilt die Konfiguration von Traffic Director auf Grundlage des in der Bootstrap-Konfiguration angegebenen VPC-Netzwerks. Deshalb müssen Sie, auch wenn sich Ihr Mesh-Netzwerk komplett außerhalb eines Google Cloud-Rechenzentrums befindet, in Ihrer Bootstrap-Konfiguration einen gültigen VPC-Netzwerknamen angeben.

Dienstkonto

In Google Cloud ist der Standard-Envoy-Bootstrap so konfiguriert, dass Dienstkontoinformationen entweder aus einer Compute Engine-Bereitstellungsumgebung oder aus einer GKE-Deployment-Umgebung oder aus beiden Umgebungen gelesen werden. Bei Ausführung außerhalb von Google Cloud müssen Sie in Ihrem Envoy-Bootstrap explizit ein Dienstkonto, einen Netzwerknamen und eine Projektnummer angeben. Für dieses Dienstkonto sind ausreichende Berechtigungen für das Herstellen einer Verbindung zur Traffic Director API erforderlich.

Nächste Schritte

Eine Anleitung zum Konfigurieren von Traffic Director für lokale und Multi-Cloud-Bereitstellungen finden Sie unter Edge-Netzwerkdienste für Bereitstellungen in mehreren Umgebungen (lokal, Multi-Cloud).