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 zur Verarbeitung von Traffic, der an einen Dienst in Ihrem Mesh-Netzwerk 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 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:

  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-Netzwerks.
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 des Service Mesh-Netzwerks und überquert nicht die Service Mesh-Datenebene.

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

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:

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 der Verwendung eines zweiten von Cloud Service Mesh konfigurierten Gateways wird im Abschnitt Traffic von einem Gateway der zweiten Ebene am Rand 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 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:

  • Back-Ends 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-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:

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

  • 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 eine der folgenden Bedingungen zutrifft:
  • Sie können eine Anfrage an einen von Google Cloud verwalteten Load-Balancer senden, der die Anfrage dann an den Edge-Proxy sendet. Weitere Informationen finden Sie unter Traffic von einem Gateway der zweiten Ebene am Rand 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)

Back-Ends in allen Google Cloud-Regionen, ausgeführt auf:

  • 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-Funktionen finden Sie auf der Seite Cloud Service Mesh-Funktionen.

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 Cloud und 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 verwalteten Load Balancern von Google Cloud 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 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:

  1. Clients senden Traffic an einen von Google Cloud verwalteten 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 Cloud verwalteten 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. 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.

  3. 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:

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

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 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.

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 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 ersten Satz von Richtlinien an, z. B. Google 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 Cloud verwalteten Load Balancer möglicherweise nicht verfügbar sind. 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:

  1. 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.

  2. 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 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 des Teams angewendet werden, unabhängig definieren und verwalten.

Dieses Muster kann mit jedem von Google Cloud verwalteten Load Balancer implementiert werden, solange der Load Balancer Traffic an die Back-Ends senden kann, auf denen die von Cloud Service Mesh konfigurierten Gateways gehostet werden.

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