Eingehender Traffic für Ihr Mesh

Ein Service Mesh vereinfacht die Kommunikation zwischen den im Mesh ausgeführten Diensten. Wie lässt sich Traffic in Ihr Mesh leiten? 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 zur Verarbeitung von Traffic, der an einen Dienst in Ihrem Mesh gerichtet 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 eine Anleitung zum Bereitstellen mit einem Ingress-Gateway.

Berücksichtigen Sie beim Entwerfen Ihres Service Mesh den Traffic, der aus den folgenden Quellen eingeht:

  • Aus Ihrem Mesh-Netzwerk stammender Traffic
  • Traffic von außerhalb Ihres Mesh-Netzwerks

Aus Ihrem Mesh-Netzwerk stammender Traffic wird über die Service-Mesh-Datenebene weitergeleitet, um ein Backend 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 aus Ihrem Mesh-Netzwerk stammt, 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:

  1. Dienst A stellt eine Anfrage an Dienst B mit seinem Namen.
  2. Diese Anfrage wird abgefangen und an den Sidecar-Proxy von Dienst A weitergeleitet.
  3. Der Sidecar-Proxy sendet die Anfrage dann an einen mit Dienst B verknüpften Endpunkt.
Die Datenebene des Mesh-Netzwerks verarbeitet den internen Traffic des Service Mesh.
Die Datenebene des Mesh-Netzwerks verarbeitet den internen Traffic des Service Mesh-Netzwerks (zum Vergrößern klicken)


Im folgenden Beispiel stammt der Traffic von außerhalb Ihres Service Mesh und bewegt sich nicht entlang der Service Mesh-Datenebene.

Die Service Mesh-Datenebene verarbeitet keine Daten außerhalb des Service Mesh.
Die Service Mesh-Datenebene verarbeitet keinen Traffic außerhalb des Service Mesh (zum Vergrößern klicken).

In diesem Beispiel befindet sich der Client außerhalb Ihres Service Mesh. Da der Client nicht direkt am Mesh-Netzwerk beteiligt ist, weiß der Client nicht, welche Endpunkte zu Diensten innerhalb des Mesh-Netzwerks 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-Netzwerks 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-Netzwerk?

Clients 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-Netzwerks 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 einGoogle Cloud -Load Balancer als Gateway auswählen, sind folgende Fragestellungen relevant:

  • 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 das 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:

  • Traffic-Verwaltung (z. B. Routing, Weiterleitungen und Anfragetransformation)
  • Sicherheit, z. B. TLS-Terminierung 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 Edge Ihres 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 Traffic-Verwaltung 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 Backend.

Im Abschnitt Gateway für das Mesh-Netzwerk auswählen werden die Backends 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-Netzwerk 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:

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 Cloudeingehenden Traffic und ein separates Gateway der zweiten Ebene verarbeitet den Traffic, wenn er in das Service Mesh eintritt.

Sie können beispielsweise Google Cloud Armor-Sicherheitsrichtlinien auf in Google Cloud eingehenden Traffic und erweiterte Richtlinien zur Traffic-Verwaltung auf in das Mesh-Netzwerk eingehenden Traffic anwenden. Das Muster der Verwendung eines zweiten von Cloud Service Mesh konfigurierten Gateways wird im Abschnitt Eingehenden Traffic mit einem Gateway der zweiten Ebene am Edge des Mesh-Netzwerks verarbeiten beschrieben.

In der folgenden Tabelle werden die verfügbaren Funktionen je nach ausgewählter Gateway-Option verglichen:

Gateway Standort des Clients Protokolle Richtlinien Backends/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 Traffic-Verwaltung

TLS-Terminierung mit selbstverwalteten Zertifikaten

Backends in derselben Google Cloud -Region wie der Load Balancer, ausgeführt auf:

  • Backends von VM-Instanzen in Compute Engine
  • Containerinstanzen in Google Kubernetes Engine (GKE) und Kubernetes
Externer Application Load Balancer Clients im öffentlichen Internet

HTTP/1.1

HTTP/2

HTTPS

Trafficverwaltung

Cloud CDN (einschließlich Cloud Storage-Bucket-Backends)

TLS-Terminierung 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

Backends in einer beliebigen Google Cloud -Region, die auf Folgendem ausgeführt werden:

  • VMs in Compute Engine
  • Containerinstanzen in GKE und Kubernetes
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 Backends 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 Backends 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)

Backends in einer beliebigen Google Cloud -Region, die auf Folgendem ausgeführt werden:

  • VMs in Compute Engine
  • Containerinstanzen in GKE und Kubernetes
Von Cloud Service Mesh konfigurierter Edge-Proxy
(auf VM- oder Containerinstanzen)		 Clients müssen sich an einem Standort befinden, auf den einer der folgenden Sachverhalte zutrifft:
  • Sie können eine Anfrage an einen von Google Cloudverwalteten Load Balancer senden, der die Anfrage dann an den Edge-Proxy sendet. Weitere Informationen finden Sie unter Eingehenden Traffic mit einem Gateway der zweiten Ebene am Edge des Mesh-Netzwerks verarbeiten.
  • Sie können eine Anfrage über einen Proxy senden, z. B. einen Sidecar-Proxy, der von Cloud Service Mesh konfiguriert wird.
  • Sie können eine Anfrage direkt an die IP-Adresse und den Port einer VM oder Containerinstanz senden, auf der der Edge-Proxy ausgeführt wird.

HTTP/1.1

HTTP/2

 Erweiterte Traffic-Verwaltung (einschließlich regex-Unterstützung)

Backends in einer beliebigen Google Cloud -Region, die auf Folgendem ausgeführt werden:

  • VMs in Compute Engine
  • Containerinstanzen in GKE und Kubernetes

Einen detaillierten Vergleich der einzelnen Features finden Sie auf der Seite Load Balancer-Features. Eine detaillierte Übersicht über die Cloud Service Mesh-Features finden Sie auf der 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

Zum Konfigurieren der verwalteten Load Balancing-Produkte von Google Cloudund Cloud Service Mesh können Sie die Google Cloud CLI und die 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 von Google Cloudverwalteten Load Balancern können Sie die Google Cloud Console verwenden.

Zum Konfigurieren Ihres Gateway-Musters benötigen Sie wahrscheinlich sowohl die Seite Cloud Service Mesh als auch die Seite Load Balancing.

GKE und Multi-Cluster-Ingress

GKE- und GKE Enterprise-Netzwerkcontroller unterstützen auch die Bereitstellung von Cloud Load Balancing für die integrierte Einbindung in Containernetzwerke. Sie bieten eine deklarative Schnittstelle im Kubernetes-Stil zum Bereitstellen und Konfigurieren von Gateways. GKE Ingress- und Multi-cluster 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 Cloudverwalteten Load Balancers als Gateway:

  1. Clients senden Traffic an einen von Google Cloudverwalteten Load Balancer, der als Gateway fungiert.

    • Das Gateway wendet Richtlinien an.

  2. Das Gateway sendet den Traffic an einen Dienst in Ihrem Mesh.

Ein komplexeres Muster umfasst Gateways auf zwei Ebenen. Die Gateways funktionieren folgendermaßen:

  1. Clients senden Traffic an einen von Google Cloudverwalteten Load Balancer, der als Gateway der ersten Ebene fungiert.

    • Das Gateway wendet Richtlinien an.

  2. Das Gateway sendet den Traffic an einen von Cloud Service Mesh konfigurierten Edge-Proxy (oder Pool von Edge-Proxys). Dieser Edge-Proxy fungiert als Gateway der zweiten Ebene. Zweck dieser Ebene:

    • Bietet eine klare Trennung von Bedenken, bei denen beispielsweise ein Team für eingehenden Traffic in Google Cloud verantwortlich ist, während ein anderes für eingehenden Traffic in das Mesh-Netzwerk dieses Teams verantwortlich ist.

    • Hiermit können Sie Richtlinien anwenden, die möglicherweise nicht im vonGoogle Cloudverwalteten Load Balancer unterstützt werden.

  3. Das Gateway der zweiten Ebene sendet den Traffic an einen Dienst in Ihrem Mesh-Netzwerk.

Das Muster für eingehenden Traffic endet, nachdem 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 undGoogle Cloud über das öffentliche Internet erreichen müssen, können Sie einen der folgenden Load Balancer als Gateway verwenden:

Eingehender Traffic von Clients im öffentlichen Internet zu In-Mesh-Diensten mit einem Load Balancer
Eingehender Traffic von Clients im öffentlichen Internet zu In-Mesh-Diensten mit einem Load Balancer (zum Vergrößern klicken)

In diesem Muster dient der von Google Cloudverwaltete Load Balancer als Gateway. Das Gateway verarbeitet eingehenden Traffic, bevor er an einen Dienst in Ihrem Mesh-Netzwerk weitergeleitet wird.

Sie können beispielsweise einen externen Application Load Balancer als Gateway auswählen, um Folgendes zu verwenden:

  • Eine öffentlich weiterleitbare globale Anycast-IP-Adresse, die Latenz und Kosten für den Netzwerkdurchlauf minimiert.
  • Google Cloud Armor und TLS-Terminierung zum Sichern des Traffics zu Ihrem Mesh-Netzwerks.
  • Cloud CDN zum Bereitstellen von Web- und Videoinhalten.
  • Traffic-Management-Funktionen wie host- und wegebasiertes 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:

Eingehender Traffic von Clients in einem VPC-Netzwerk zu In-Mesh-Diensten mit einem Load Balancer.
Eingehender Traffic von Clients in einem VPC-Netzwerk zu In-Mesh-Diensten mit einem Load Balancer (zum Vergrößern klicken)

In diesem Muster dient der von Google Cloudverwaltete Load Balancer als Gateway. Das Gateway verarbeitet eingehenden Traffic, bevor er an einen Dienst in Ihrem Mesh-Netzwerk weitergeleitet wird.

Sie können beispielsweise einen internen Application Load Balancer als Gateway auswählen, um diese Features nutzen zu können:

  • Eine privat adressierbare IP-Adresse
  • TLS-Terminierung zum Sichern Ihres Mesh-Netzwerks
  • Erweiterte Funktionen zur Trafficverwaltung wie gewichtete Trafficaufteilung
  • NEGs als Backends

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 Edge des Mesh-Netzwerks verarbeiten

Je nach Ihren Anforderungen können Sie ein komplexeres Muster in Betracht ziehen, das ein zusätzliches Gateway hinzufügt.

Eingehender Traffic von externen Clients zu In-Mesh-Diensten mithilfe eines Load Balancers und eines Edge-Proxys.
Eingehender Traffic von externen Clients zu In-Mesh-Diensten mit einem Load Balancer und einem Edge-Proxy (zum Vergrößern klicken)

Dieses Gateway ist ein von Cloud Service Mesh konfigurierter Edge-Proxy (oder Pool von Proxys), der sich hinter dem von Google Cloudverwalteten 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 Cloudverwaltete Load Balancer wendet einen ersten Satz von Richtlinien an, z. B. Cloud Armor-Schutz, wenn Sie einen externen Application Load Balancer verwenden.

  • Der von Cloud Service Mesh konfigurierte Edge-Proxy wendet einen zweiten Satz von Richtlinien an, die im von Google Cloudverwalteten Load Balancer möglicherweise nicht verfügbar sind. Zu diesen Richtlinien gehören die erweiterte Traffic-Verwaltung mit regulären Ausdrücken, die auf HTTP-Header angewendet werden, und die gewichtete Aufteilung des Traffics.

Dieses Muster kann an Ihre Organisationsstruktur angepasst werden. Beispiel:

  1. Ein Team ist möglicherweise für die Verarbeitung von eingehendem Traffic zuGoogle Cloud verantwortlich, während ein anderes für eingehenden Traffic zu seinem Mesh-Netzwerk zuständig ist.

  2. Wenn mehrere Teams Dienste auf einer gemeinsam genutzten 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 ein von Cloud Service Mesh konfiguriertes Gateway bereitstellen, das über eine einzelne IP-Adresse und ein einzelnes Portpaar erreichbar ist. Ein Team kann dann die Richtlinien, die auf eingehenden Traffic auf das Mesh-Netzwerk des Teams angewendet werden, unabhängig definieren und verwalten.

Dieses Muster kann mit jedem von Google Cloudverwalteten Load Balancer implementiert werden, solange der Load Balancer Traffic an die Backends senden kann, auf denen die für Cloud Service Mesh konfigurierten Gateways gehostet werden.

Service Routing APIs für eingehenden Traffic verwenden

Die Service Routing 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 Service Routing – Übersicht und unter Ingress-Gateway einrichten.

Nächste Schritte