Eingehender Traffic für Ihr Mesh
Ein Service Mesh vereinfacht die Kommunikation zwischen den im Mesh ausgeführten Diensten. Aber wie leiten Sie Traffic in Ihr Mesh-Netzwerk? Sie können ein Gateway verwenden, um Traffic von außerhalb Ihres Mesh-Netzwerks über einen Einstiegspunkt an Ihr Mesh-Netzwerk zu leiten.
In diesem Dokument wird beschrieben, wie Sie Cloud Load Balancing als Gateway verwenden, um Traffic an Ihr Mesh-Netzwerk zu leiten. Es enthält folgende Themen:
- Allgemeine Überlegungen zu Ihrem Gateway.
- Eine Übersicht über die Optionen, wenn Sie ein Gateway für Ihr Mesh auswählen.
- Architektonische Empfehlungen, die Sie auf Ihre Gateway-Topologie anwenden können-
In diesem Dokument bezieht sich Gateway auf eine Lösung oder ein Muster für die Verarbeitung. Traffic, der für einen Dienst in Ihrem Mesh bestimmt ist. Das Ingress-Gateway von Istio ist eine Implementierung dieses Musters. In diesem Dokument ist Gateway ein allgemeiner Begriff, der sich auf das allgemeine Muster und nicht auf die Istio-Implementierung bezieht.
Dieses Dokument bezieht sich auf die Cloud Service Mesh APIs. Nach den vorbereitenden Einrichtungsschritten finden Sie unter Traffic Director-Einrichtung für ein Ingress-Gateway eine Anleitung zum Bereitstellen mit einem Ingress-Gateway.
Berücksichtigen Sie beim Entwerfen Ihres Service Mesh-Netzwerks Traffic, der aus den folgenden Quellen eingeht:
- Traffic aus Ihrem Mesh-Netzwerk
- Traffic von außerhalb Ihres Mesh-Netzwerks
Aus Ihrem Mesh-Netzwerk stammender Traffic wird über die Service-Mesh-Datenebene weitergeleitet, um ein Back-End oder einen Endpunkt zu erreichen, der mit dem Zieldienst verknüpft ist. Traffic von außerhalb Ihres Mesh-Netzwerks muss jedoch zuerst die Service Mesh-Datenebene erreichen.
Im folgenden Beispiel für Traffic, der von Ihrem Mesh-Netzwerk ausgeht, konfiguriert Cloud Service Mesh Ihre Sidecar-Proxys. Diese Sidecar-Proxys bilden die Datenebene Ihres Service Mesh. Wenn Dienst A mit Dienst B kommunizieren möchte, geschieht Folgendes:
- Dienst A stellt eine Anfrage an Dienst B mit seinem Namen.
- Diese Anfrage wird abgefangen und an den Sidecar-Proxy von Dienst A weitergeleitet.
- Der Sidecar-Proxy sendet die Anfrage dann an einen mit Dienst B verknüpften Endpunkt.
Im folgenden Beispiel stammt der Traffic von außerhalb des Service Mesh-Netzwerks und überquert nicht die Service Mesh-Datenebene.
In diesem Beispiel befindet sich der Client außerhalb Ihres Service Mesh-Netzwerks. Da der Client nicht direkt am Mesh beteiligt ist, weiß der Client nicht, welche Endpunkte zu Diensten innerhalb des Mesh gehören. Anders ausgedrückt: Da der Client ausgehende Anfragen nicht über einen von Cloud Service Mesh konfigurierten Proxy sendet, weiß er nicht, welche Paare aus IP-Adresse/Port beim Senden von Traffic an Dienst A oder Dienst B verwendet werden sollen. Ohne diese Informationen kann der Client keine Dienste innerhalb Ihres Mesh erreichen.
Überlegungen zu Ihrem Gateway
In diesem Abschnitt erhalten Sie eine Übersicht über die Probleme, die bei der Auswahl eines Gateways zu berücksichtigen sind, darunter:
- Wie können Clients mein Gateway erreichen?
- Welche Richtlinien möchte ich auf Traffic anwenden, der mein Gateway erreicht?
- Wie verteilt mein Gateway den Traffic auf Dienste in meinem Mesh?
Clients den Zugriff auf das Gateway zu Ihrem Mesh-Netzwerk ermöglichen
Clients, ob im öffentlichen Internet, in Ihrer lokalen Umgebung oder innerhalb von Google Cloud, benötigen eine Möglichkeit, um einen Dienst innerhalb Ihres Mesh zu erreichen. Der Zugriff auf einen Dienst in Ihrem Mesh-Netzwerk erfolgt normalerweise über eine öffentlich oder privat routingfähige IP-Adresse und einen Port, der in ein Gateway aufgelöst wird. Clients außerhalb Ihres Mesh-Netzwerks verwenden diese IP-Adresse und diesen Port, um Anfragen über Ihr Gateway an Dienste in Ihrem Mesh-Netzwerk zu senden.
Cloud Load Balancing bietet verschiedene Load-Balancing-Optionen, die Sie als Gateway für Ihr Mesh-Netzwerk verwenden können. Wenn Sie ein Google Cloud-Load-Balancer als Gateway auswählen, sollten Sie folgende Fragen stellen:
- Befinden sich meine Clients im öffentlichen Internet, in einer lokalen Umgebung oder in einem VPC-Netzwerk (Virtual Private Cloud)?
- Welche Kommunikationsprotokolle verwenden meine Clients?
Eine Übersicht über die Cloud Load Balancing-Optionen, die vom Clientstandort und Kommunikationsprotokoll abhängen, finden Sie im Abschnitt Gateway für Ihr Mesh-Netzwerk auswählen.
Traffic am Gateway verarbeiten
Da sich das Gateway am Rand des Mesh-Netzwerks befindet – zwischen Clients außerhalb des Mesh-Netzwerks und Diensten innerhalb des Mesh-Netzwerks – ist das Gateway ein idealer Ort, um Richtlinien anzuwenden, wenn Traffic in das Mesh-Netzwerk eintritt. Zu diesen Richtlinien gehören:
- Trafficverwaltung (z. B. Routing, Weiterleitungen und Anfragetransformation)
- Sicherheit, z. B. TLS-Beendigung und DDoS-Schutz (Distributed Denial of Service) von Google Cloud Armor
- Cloud CDN-Caching
Im Abschnitt Gateway für das Mesh-Netzwerk auswählen werden Richtlinien hervorgehoben, die am Rand des Mesh-Netzwerks relevant sind.
Traffic vom Gateway an einen Dienst in Ihrem Mesh-Netzwerk senden
Nachdem Ihr Gateway Richtlinien auf eingehenden Traffic angewendet hat, entscheidet das Gateway, wohin der Traffic gesendet werden soll. Für die Konfiguration verwenden Sie Richtlinien zur Trafficverwaltung und zum Load-Balancing. Das Gateway kann beispielsweise den Anfrageheader prüfen, um den Mesh-Dienst zu identifizieren, der den Traffic empfangen soll. Nachdem das Gateway den Dienst identifiziert hat, verteilt es den Traffic gemäß einer Load-Balancing-Richtlinie auf ein bestimmtes Back-End.
Im Abschnitt Gateway für das Mesh-Netzwerk auswählen werden die Back-Ends beschrieben, an die ein Gateway Traffic senden kann.
Gateway für das Mesh-Netzwerk auswählen
Google Cloud bietet eine Vielzahl von Load-Balancern, die als Gateway zu Ihrem Mesh dienen können. In diesem Abschnitt wird die Auswahl eines Gateways erläutert. Dabei werden die folgenden Optionen mit Dimensionen verglichen, die für das Gateway-Muster relevant sind:
- Interner Application Load Balancer
- Externer Application Load Balancer
- Interner Passthrough-Network Load Balancer
- Externer Passthrough Network Load Balancer
- Externer Proxy-Network Load Balancer
In diesem Abschnitt beziehen wir uns auf Gateways der ersten und zweiten Ebene. Diese Begriffe beschreiben die Verwendung eines oder zwei Gateways zur Verarbeitung von eingehendem Traffic zu Ihrem Mesh-Netzwerk.
Möglicherweise benötigen Sie nur eine Ebene, einen einzelnen Load-Balancer, der als Gateway für das Mesh-Netzwerk fungiert. Manchmal sind jedoch mehrere Gateways sinnvoll. In diesen Konfigurationen verarbeitet ein Gateway den in Google Cloud eingehenden Traffic und ein separates Gateway der zweiten Ebene verarbeitet den Traffic, wenn er in das Service Mesh-Netzwerk eintritt.
Sie können beispielsweise Google Cloud Armor-Sicherheitsrichtlinien auf eingehenden Traffic in Google Cloud und erweiterte Richtlinien zur Trafficverwaltung auf eingehenden Traffic in Mesh anwenden. Das Muster, bei dem eine Das vom Cloud Service Mesh konfigurierte Gateway wird im Abschnitt erläutert Verarbeiten Sie eingehenden Traffic mit einem Gateway der zweiten Ebene am Rand Ihres Mesh.
In der folgenden Tabelle werden die verfügbaren Funktionen je nach ausgewählter Gateway-Option verglichen:
| Gateway | Standort des Clients | Protokolle | Richtlinien | Back-Ends/Endpunkte |
|---|---|---|---|---|
| Interner Application Load Balancer | Google Cloud-basierte Clients in derselben Region wie der Load-Balancer. Lokale Clients, deren Anfragen in derselben Google Cloud-Region wie der Load-Balancer ankommen, z. B. mit Cloud VPN oder Cloud Interconnect. |
HTTP/1.1 HTTP/2 HTTPS |
Erweiterte Trafficverwaltung TLS-Terminierung mit selbstverwalteten Zertifikaten |
Back-Ends in derselben Google Cloud-Region wie der Load-Balancer, ausgeführt auf:
|
| Externer Application Load Balancer | Clients im öffentlichen Internet. | HTTP/1.1 HTTP/2 HTTPS |
Trafficverwaltung Cloud CDN (einschließlich Cloud Storage-Bucket-Back-Ends) TLS-Beendigung mit Google- oder selbstverwalteten Zertifikaten SSL-Richtlinien Google Cloud Armor für DDoS und Schutz vor Webangriffen IAP-Unterstützung (Identity-Aware Proxy) für Nutzerauthentifizierung |
Back-Ends in allen Google Cloud-Regionen, ausgeführt auf:
|
| Interner Passthrough-Network-Load-Balancer | Google Cloud-basierte Clients in jeder beliebigen Region. Dies erfordert globalen Zugriff, wenn sich Clients in einer anderen Region als der Load-Balancer befinden. Lokale Clients, deren Anfragen in einer beliebigen Google Cloud-Region eingehen (z. B. über Cloud VPN oder Cloud Interconnect) |
TCP | Back-Ends in derselben Google Cloud-Region wie der Load-Balancer, der auf VMs in Compute Engine ausgeführt wird. | |
| Externer Passthrough-Network Load Balancer | Clients im öffentlichen Internet. | TCP oder UDP | Back-Ends in derselben Google Cloud-Region wie der Load-Balancer, der auf VMs in Compute Engine ausgeführt wird. | |
| Externer Proxy-Network Load Balancer | Clients im öffentlichen Internet. | SSL oder TCP | TLS-Terminierung mit Google- oder selbstverwalteten Zertifikaten (nur SSL-Proxy) SSL-Richtlinien (nur SSL-Proxy) |
Back-Ends in allen Google Cloud-Regionen, ausgeführt auf:
|
| Edge-Proxy (auf VM- oder Containerinstanzen), konfiguriert von Cloud-Service-Mesh |
Clients müssen sich an einem Standort befinden, auf den eine der folgenden Bedingungen zutrifft:
|
HTTP/1.1 HTTP/2 |
Erweiterte Traffic-Verwaltung (einschließlich regex-Unterstützung) |
Back-Ends in allen Google Cloud-Regionen, ausgeführt auf:
|
Einen detaillierten Vergleich der einzelnen Features finden Sie auf der Seite Load-Balancer-Features. Eine detaillierte Übersicht über die Features von Cloud Service Mesh finden Sie in den Seite Cloud Service Mesh-Features
Gateways bereitstellen und konfigurieren
Eine letzte Überlegung bei der Auswahl Ihres Gateways ist die Entwicklererfahrung und die Tools, die Sie verwenden möchten. Google Cloud bietet mehrere Ansätze zum Erstellen und Verwalten Ihres Gateways.
Google Cloud CLI und Compute Engine APIs
Um die verwalteten Load-Balancing-Produkte von Google Cloud und Cloud Service Mesh können Sie die Google Cloud CLI und Compute Engine APIs verwenden. Die gcloud CLI und die APIs bieten Mechanismen zum imperativen Bereitstellen und Konfigurieren Ihrer Google Cloud-Ressourcen. Sie können Skripts erstellen, um wiederkehrende Aufgaben zu automatisieren.
Google Cloud Console
Zum Konfigurieren von Cloud Service Mesh und verwalteten Load Balancern von Google Cloud können Sie die Google Cloud Console verwenden.
Zum Konfigurieren des Gateway-Musters benötigen Sie wahrscheinlich sowohl das Seite Cloud Service Mesh und die Seite Load-Balancing.
GKE und Multi-Cluster-Ingress
GKE- und GKE Enterprise-Netzwerkcontroller unterstützen auch der Bereitstellung von Cloud Load Balancing für die Integration in Containernetzwerke. Sie bieten eine deklarative Schnittstelle im Kubernetes-Stil zum Bereitstellen und Konfigurieren von Gateways. GKE Ingress- und Anthos Ingress-Controller verwalten interne und externe Load-Balancer, um Traffic an einen einzelnen Cluster oder über mehrere GKE-Cluster zu senden. Die Ingress-Ressource kann auch so konfiguriert werden, dass sie auf von Cloud Service Mesh konfigurierte Dienste verweist, die in GKE-Clustern bereitgestellt werden.
Gateway-Architekturmuster
In diesem Abschnitt werden allgemeine Muster und Architekturdiagramme für Ihr Gateway beschrieben.
Das gängigste Muster ist die Verwendung eines von Google Cloud verwalteten Load-Balancers als Gateway:
Clients senden Traffic an einen von Google Cloud verwalteten Load-Balancer, der als Gateway fungiert.
- Das Gateway wendet Richtlinien an.
Das Gateway sendet den Traffic an einen Dienst in Ihrem Mesh.
Ein komplexeres Muster umfasst Gateways auf zwei Ebenen. Die Gateways funktionieren folgendermaßen:
Clients senden Traffic an einen von Google Cloud verwalteten Load-Balancer, der als Gateway der ersten Ebene fungiert.
- Das Gateway wendet Richtlinien an.
Das Gateway sendet den Traffic an einen Edge-Proxy (oder Pool von Edge-Proxys) das vom Cloud Service Mesh konfiguriert wurde. Dieser Edge-Proxy fungiert als Gateway der zweiten Ebene. Diese Ebene tut Folgendes:
Bietet eine klare Trennung von Bedenken, bei denen beispielsweise ein Team für eingehenden Traffic in Google Cloud verantwortlich sein kann, während ein anderes für eingehenden Traffic in das Mesh dieses Teams verantwortlich ist.
Hiermit können Sie Richtlinien anwenden, die möglicherweise nicht im von Google Cloud verwalteten Load-Balancer unterstützt werden.
Das Gateway der zweiten Ebene sendet den Traffic an einen Dienst in Ihrem Mesh.
Das Ingress-Muster endet, sobald der Traffic einen In-Mesh-Dienst erreicht. In den folgenden Abschnitten werden sowohl der gängige Fall als auch die erweiterten Muster beschrieben.
Eingehenden Traffic aus dem Internet aktivieren
Wenn sich die Clients außerhalb von Google Cloud befinden und Google Cloud über das öffentliche Internet erreichen müssen, können Sie einen der folgenden Load-Balancer als Gateway verwenden:
- Externer Application Load Balancer
- Externer Passthrough Network Load Balancer
- Externer Proxy-Network Load Balancer
In diesem Muster dient der von Google Cloud verwaltete Load-Balancer als Gateway. Das Gateway verarbeitet eingehenden Traffic, bevor er an einen Dienst in Ihrem Mesh weitergeleitet wird.
Beispielsweise können Sie einen externen Application Load Balancer als Gateway für verwenden Sie Folgendes:
- Eine öffentlich weiterleitbare globale Anycast-IP-Adresse, die Latenz und Kosten für den Netzwerkdurchlauf minimiert.
- Google Cloud Armor und TLS-Beendigung zum Sichern des Traffics zu Ihrem Mesh-Netzwerk.
- Cloud CDN zum Bereitstellen von Web- und Videoinhalten.
- Funktionen zur Trafficverwaltung wie host- und pfadbasiertes Routing
Weitere Informationen zur Auswahl eines geeigneten Gateways finden Sie im Abschnitt Gateway für Ihr Mesh-Netzwerk auswählen.
Eingehenden Traffic von Clients in VPC- und verbundenen lokalen Netzwerken aktivieren
Wenn sich Ihre Clients innerhalb des VPC-Netzwerks befinden oder lokal sind und Google Cloud-Dienste über eine private Verbindungsmethode (z. B. Cloud VPN oder Cloud Interconnect) erreichen können, verwenden Sie einen der folgenden Load-Balancer als Gateway:
In diesem Muster dient der von Google Cloud verwaltete Load-Balancer als Gateway. Das Gateway verarbeitet eingehenden Traffic, bevor er an einen Dienst in Ihrem Mesh weitergeleitet wird.
Sie können beispielsweise einen internen Application Load Balancer als Gateway auswählen, um diese Funktionen nutzen zu können:
- Eine privat adressierbare IP-Adresse
- TLS-Beendigung zum Sichern Ihres Mesh
- Erweiterte Funktionen zur Trafficverwaltung wie gewichtete Trafficaufteilung
- NEGs als Back-Ends
Weitere Informationen zur Auswahl eines geeigneten Gateways finden Sie im Abschnitt Gateway für Ihr Mesh-Netzwerk auswählen.
Eingehenden Traffic mit einem Gateway der zweiten Ebene am Rand des Mesh-Netzwerks verarbeiten
Je nach Ihren Anforderungen können Sie ein komplexeres Muster in Betracht ziehen, das ein zusätzliches Gateway hinzufügt.
Dieses Gateway ist ein von Cloud Service Mesh konfigurierter Edge-Proxy (oder Pool von Proxys), der sich hinter dem von Google Cloud verwalteten Load Balancer befindet. Sie können dieses Gateway der zweiten Ebene in Ihrem Projekt mithilfe eines Pools von Compute Engine-VMs (einer verwalteten Instanzgruppe) oder GKE-Diensten hosten.
Dieses Muster ist zwar komplexer, bietet jedoch zusätzliche Vorteile:
Der von Google Cloud verwaltete Load-Balancer wendet einen anfänglichen Satz von wie z. B. den Google Cloud Armor-Schutz, wenn Sie einen externen Application Load Balancer.
Der von Cloud Service Mesh konfigurierte Edge-Proxy wendet einen zweiten Satz Richtlinien, die in der von Google Cloud verwalteten Last möglicherweise nicht verfügbar sind aus. Zu diesen Richtlinien gehören die erweiterte Trafficverwaltung mit regulären Ausdrücken, die auf HTTP-Header angewendet werden, und die gewichtete Traffic-Aufteilung.
Dieses Muster kann an Ihre Organisationsstruktur angepasst werden. Beispiel:
Ein Team ist möglicherweise für die Verarbeitung von eingehendem Traffic zu Google Cloud verantwortlich, während ein anderes für eingehenden Traffic zu seinem Mesh zuständig ist.
Wenn mehrere Teams Dienste auf einer freigegebenen VPC anbieten und jedes Team ein eigenes Dienstprojekt besitzt, können Teams dieses Muster verwenden, um Richtlinien in ihren eigenen Mesh-Netzwerken zu verwalten und anzuwenden. Jedes Team kann eine Von Cloud Service Mesh konfiguriertes Gateway, das über eine einzelne IP-Adresse erreichbar ist Adresse und Port-Paar. Ein Team kann dann die Richtlinien, die auf eingehenden Traffic auf das Mesh des Teams angewendet werden, unabhängig definieren und verwalten.
Dieses Muster kann mit jedem von Google Cloud verwalteten Load-Balancer, solange der Load-Balancer Traffic an die Back-Ends senden kann die die für Cloud Service Mesh konfigurierten Gateways hosten.
Dienstrouting-APIs für eingehenden Traffic verwenden
Die Dienstrouting-APIs stellen die Gateway-Ressource zum Konfigurieren der Traffic-Verwaltung und der Sicherheit für Envoy-Proxys bereit, die als Ingress-Gateways fungieren und externen Clients die Verbindung mit dem Service Mesh (Nord-Süd) ermöglichen.
Weitere Informationen finden Sie in der Übersicht über das Dienstrouting und unter Ingress-Gateway einrichten.
Nächste Schritte
- Informationen zum Einrichten eines Ingress-Gateways finden Sie unter Cloud Service Mesh für ein Ingress-Gateway einrichten.
- So gruppieren Sie die VMs und Container, die Ihren Code ausführen, als Endpunkte Ihres finden Sie unter Cloud Service Mesh-Diensterkennung.
- Informationen zur Verwendung von Cloud Service Mesh mit freigegebene VPC finden Sie unter Multi-Cluster-Service Mesh einrichten
- Weitere Informationen zu Cloud Service Mesh finden Sie unter Cloud Service Mesh – Übersicht.