Cloud Service Mesh mit Netzwerk-Endpunktgruppen für Hybridkonnektivität
Cloud Service Mesh unterstützt Umgebungen, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere öffentliche Clouds, Hybridkonnektivität erreicht.
Sie konfigurieren Cloud Service Mesh so, dass Ihr Service Mesh Traffic an folgende Adresse senden kann: Endpunkte außerhalb von Google Cloud. Zu diesen Endpunkten gehören:
- Lokale Load-Balancer.
- Serveranwendungen auf einer VM-Instanz in einer anderen Cloud.
- Andere Ziele, die Sie mit Hybridkonnektivität erreichen können und die mit einer IP-Adresse und einem Port erreichbar sind.
Sie fügen dazu einer Netzwerk-Endpunktgruppe (NEG) mit Hybridkonnektivität die IP-Adresse und den Port jedes Endpunkts hinzu. Hybridkonnektivitäts-NEGs sind vom Typ NON_GCP_PRIVATE_IP_PORT
.
Cloud Service Mesh-Unterstützung für lokale und Multi-Cloud-Dienste können Sie Folgendes tun:
- Sie können Traffic global weiterleiten, auch an die Endpunkte lokaler und Multi-Cloud-Dienste.
- Nutzen Sie die Vorteile von Cloud Service Mesh und Service Mesh – einschließlich wie Diensterkennung und erweiterte Traffic-Verwaltung, um Dienste, die in Ihrer vorhandenen Infrastruktur außerhalb von Google Cloud ausgeführt werden.
- Kombinieren Sie Cloud Service Mesh-Funktionen mit Cloud Load Balancing, um Google Cloud-Netzwerkdienste in mehreren Umgebungen bereitstellen.
NEGs für die Hybridkonnektivität (NON_GCP_PRIVATE_IP_PORT
NEGs) werden von proxylosen gRPC-Clients nicht unterstützt.
Anwendungsfälle
Cloud Service Mesh kann Netzwerke zwischen VM- und containerbasiert konfigurieren Dienste in mehreren Umgebungen, z. B.:
- 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. Ihr Anwendung führt einen Cloud Service Mesh-Envoy-Proxy aus . Cloud Service Mesh informiert den Client über Ihre Dienste und die Endpunkte jedes Dienstes.
Wenn im obigen Diagramm Ihre Anwendung eine Anfrage an den on-prem
-Dienst sendet, prüft der Cloud Service Mesh-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.
Wenn Sie weitere Endpunkte hinzufügen müssen, aktualisieren Sie das Cloud Service Mesh, um sie Ihren Dienst. Sie müssen den Anwendungscode nicht ändern.
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 zu migrieren.
Das obige Diagramm erweitert das vorherige Muster. Anstelle der Konfiguration
Cloud Service Mesh zum Senden des gesamten Traffics an den on-prem
-Dienst verwendet,
Cloud Service Mesh so konfigurieren, dass die Trafficaufteilung nach Gewichtung zum Aufteilen verwendet wird
Traffic für zwei Dienste.
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 ein breites Spektrum an wie das globale externe Load-Balancing mit Google Cloud Armor DDoS-Schutz (Distributed Denial of Service), den Sie mit Cloud Service Mesh für neue Funktionen in Ihrer lokalen Umgebung oder Multi-Cloud . Diese lokalen oder Multi-Cloud-Dienste müssen dabei nicht über das öffentliche Internet verfügbar sein.
Im obigen Diagramm wird Traffic von Clients im öffentlichen Internet Google Cloud-Netzwerk von einem Google Cloud-Load-Balancer, z. B. unseren globalen externen Application Load Balancer. Sobald der Traffic den Load-Balancer erreicht, können Sie Edge-Netzwerkdienste wie den DDoS-Schutz von Google Cloud Armor oder die IAP-Nutzerauthentifizierung (Identity-Aware Proxy) anwenden. Weitere Informationen finden Sie unter Edge-Netzwerkdienste für Bereitstellungen in mehreren Umgebungen.
Nachdem Sie diese Dienste angewendet haben, wird der Traffic in Google Cloud, wobei eine Anwendung oder ein eigenständiger Proxy (konfiguriert von Cloud Service Mesh) den Traffic über Cloud VPN oder Cloud Interconnect zu Ihrem lokalen Dienst
Ressourcen und Architektur von Google Cloud
Dieser Abschnitt enthält Hintergrundinformationen zu Google Cloud Ressourcen, mit denen Sie ein von Cloud Service Mesh verwaltetes Service Mesh bereitstellen können für lokale und Multi-Cloud-Umgebungen.
Das folgende Diagramm zeigt die Google Cloud-Ressourcen, Unterstützung lokaler und Multi-Cloud-Dienste für Cloud Service Mesh. Die Schlüsselressource ist die NEG und deren Netzwerkendpunkte. Die anderen Ressourcen sind Die Ressourcen, die Sie im Rahmen einer Cloud Service Mesh-Standardeinrichtung konfigurieren. Der Einfachheit halber sind im Diagramm keine Optionen wie mehrere globale Back-End-Dienste zu sehen.
Wenn Sie Cloud Service Mesh konfigurieren, verwenden Sie die API für globale Back-End-Dienste. Ressource zum Erstellen von Diensten. Ein Dienst ist ein logisches Konstrukt, das Folgendes kombiniert:
- Richtlinien, die angewendet werden sollen, wenn ein Client versucht, Traffic an den Dienst zu senden
- Ein oder mehrere Back-Ends oder Endpunkte, die den Traffic verarbeiten, der für den Dienst bestimmt ist
Lokale und Multi-Cloud-Dienste sind
wie jeder andere Dienst,
Cloud Service Mesh konfiguriert. Der Hauptunterschied besteht darin, dass Sie für die Konfiguration der Endpunkte dieser Dienste eine Hybridkonnektivitäts-NEG verwenden. Bei diesen NEGs ist der Netzwerk-Endpunkt-Typ auf NON_GCP_PRIVATE_IP_PORT
gesetzt. Die Endpunkte, die Sie den Hybridkonnektivitäts-NEGs hinzufügen, müssen gültige IP:port
-Kombinationen sein, die Ihre Clients erreichen können, z. B. über Hybridkonnektivität wie Cloud VPN oder Cloud Interconnect.
Jede NEG hat einen Netzwerkendpunkttyp und kann nur Netzwerkendpunkte eines Typs enthalten. Dieser Typ bestimmt Folgendes:
- 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 hosten, können Sie beim Erstellen der NEG die Google Cloud-Zone
europe-west3-a
angeben.
Das Verhalten von Systemdiagnosen für Netzwerkendpunkte dieses Typs unterscheidet sich von Systemdiagnosen für andere Arten von Netzwerkendpunkten. Während andere Typen von Netzwerkendpunkten das zentrale System von Google Cloud verwenden, nutzen NON_GCP_PRIVATE_IP_PORT
-Netzwerkendpunkte das Verfahren der verteilten Systemdiagnose von Envoy. Weitere Informationen finden Sie im Abschnitt Einschränkungen und weitere Überlegungen.
Informationen zu Konnektivität und Netzwerken
Ihre Cloud Service Mesh-Clients, z. B. Envoy-Proxys, müssen eine Verbindung herstellen können
zum Cloud Service Mesh unter trafficdirector.googleapis.com:443
. Verlieren
Verbindung zur Cloud Service Mesh-Steuerungsebene hat, geschieht Folgendes:
- Vorhandene Cloud Service Mesh-Clients können keine Konfigurationsaktualisierungen von Cloud Service Mesh erhalten. Sie funktionieren weiterhin gemäß ihrer aktuellen Konfiguration.
- Neue Cloud Service Mesh-Clients können keine Verbindung zu Cloud Service Mesh 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 eine Hochverfügbarkeitsverbindung, die von Cloud VPN oder Cloud Interconnect aktiviert wird.
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
Im Folgenden sind die Einschränkungen bei der Verwendung von Hybridkonnektivitäts-NEGs aufgeführt:
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 Backend-Typen
Ein Back-End-Dienst kann VM- oder NEG-Back-Ends haben. Wenn ein Back-End-Dienst eine NEG hat Back-Ends müssen alle NEGs denselben Netzwerk-Endpunkttyp enthalten. Es sind keine Back-End-Dienste mit mehreren NEGs mit unterschiedlichen Endpunkttypen möglich.
Eine URL-Zuordnung kann Hostregeln haben, die zu einem anderen Back-End aufgelöst werden. . Möglicherweise haben Sie einen Back-End-Dienst mit nur Hybridkonnektivitäts-NEGs (mit lokalen Endpunkten) und einem Back-End-Dienst mit eigenständigen NEGs (mit GKE-Endpunkten). Die URL-Zuordnung kann beispielsweise Regeln enthalten: Gewichtete Trafficaufteilung, bei der der Traffic zwischen den einzelnen Back-Ends aufgeteilt wird .
NEG mit Endpunkten vom Typ NON_GCP_PRIVATE_IP_PORT
mit Google Cloud-Back-Ends verwenden
Es ist möglich, einen Back-End-Dienst mit einer Hybridkonnektivitäts-NEG zu erstellen, verweist auf Back-Ends in Google Cloud. 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 Google Cloud NEG REST APIs oder die Google Cloud CLI 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 verwalteten Instanzgruppen von Compute Engine (Managed Instance Groups, 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
NON_GCP_PRIVATE_IP_PORT
, Cloud Service Mesh konfiguriert seine Clients so, dass sie die Datenebene für die Systemdiagnose verwenden. 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, der API oder der Google Cloud CLI abrufen.
In der Praxis bedeutet die Verwendung von NON_GCP_PRIVATE_IP_PORT
Folgendes:
- Da Cloud Service Mesh-Clients jeweils eine Systemdiagnose in einem
kann der Netzwerkverkehr steigen, wenn
. Die Erhöhung hängt von der Anzahl des Cloud Service Mesh ab
Clients und die Anzahl der Endpunkte, die jeder Client für das
überprüfen. Beispiel:
- Wenn Sie einer Hybridkonnektivitäts-NEG einen weiteren Endpunkt hinzufügen, Cloud Service Mesh-Clients beginnen möglicherweise mit der Systemdiagnose der Endpunkte Hybridkonnektivitäts-NEGs.
- Wenn Sie Ihrem Service Mesh eine weitere Instanz hinzufügen (z. B. eine VM) -Instanz, die Ihren Anwendungscode ausführt, sowie eine Cloud Service Mesh-Client), wird die neue Instanz möglicherweise in Betrieb genommen. die Endpunkte in Hybridkonnektiv-NEGs prüfen.
- Netzwerktraffic aufgrund von Systemdiagnosen steigt quadratisch (
O(n^2)
) an.
VPC-Netzwerk
Ein Service Mesh wird eindeutig durch seinen VPC-Netzwerknamen (Virtual Private Cloud) identifiziert. Cloud Service Mesh-Clients empfangen die Konfiguration vom Cloud Service Mesh basierend auf dem im Bootstrap angegebenen VPC-Netzwerk Konfiguration. 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. Dieses Dienstkonto muss Ausreichend Berechtigungen zum Herstellen einer Verbindung zur Cloud Service Mesh API
Nächste Schritte
- Informationen zum Konfigurieren von Cloud Service Mesh für lokale und Multi-Cloud-Bereitstellungen finden Sie unter Edge-Netzwerkdienste für Bereitstellungen in mehreren Umgebungen.
- Weitere Informationen zum Cloud Service Mesh finden Sie in der Cloud Service Mesh – Übersicht
- Informationen zu Internet-NEGs finden Sie unter Cloud Service Mesh mit Internetnetzwerk-Endpunktgruppen.