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? Dieser Schritt, bei dem Traffic von außerhalb Ihres Mesh über einen Einstiegspunkt in Ihr Mesh geleitet wird, kann mithilfe eines Gateways gelöst werden.

In diesem Dokument wird beschrieben, wie Sie Cloud Load Balancing als Gateway verwenden, um Traffic in Ihr Mesh zu leiten.

Übersicht

Beim Entwerfen Ihres Service Mesh müssen Sie Traffic von diesen Quellen berücksichtigen:

  • Traffic, der von Ihrem Mesh stammt
  • Traffic, der von außerhalb Ihres Mesh stammt

Der von innerhalb Ihres Mesh stammende Traffic wird auf der Service-Mesh-Datenebene weitergeleitet, um ein Back-End oder einen Endpunkt zu erreichen, der mit dem Zieldienst verknüpft ist. Traffic, der von außerhalb Ihres Mesh stammt, muss jedoch zuerst die Service-Mesh-Datenebene erreichen.

Im folgenden Beispiel für Traffic, der von Ihrem Mesh ausgeht, konfiguriert Traffic Director Ihre Sidecar-Proxys. Diese Sidecar-Proxys bilden die Datenebene Ihres Service Mesh. Wenn Dienst A mit Dienst B kommunizieren möchte:

  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.
Service Mesh-interner Traffic, der von der Service Mesh-Datenebene verarbeitet wird (zum Vergrößern klicken)
Der interne Traffic des Service Mesh wird über die Datenebene des Mesh verarbeitet (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.

Traffic außerhalb des Service Mesh wird nicht von der Service Mesh-Datenebene verarbeitet (zum Vergrößern klicken).
Traffic außerhalb des Service Mesh wird nicht von der Service Mesh-Datenebene verarbeitet (zum Vergrößern klicken)

In diesem Beispiel befindet sich der Client außerhalb Ihres Service Mesh. 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 keine ausgehenden Anfragen über einen von Traffic Director konfigurierten Proxy sendet, weiß er nicht, welche IP-Adress-Port-Paare 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.

Die in diesem Dokument beschriebenen Gateway-Muster helfen Ihnen, dieses Problem zu lösen: Wie gelangt Traffic in Ihr Mesh?

Dieses Dokument bietet Folgendes:

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

Überlegungen zu Ihrem Gateway

In diesem Abschnitt erhalten Sie eine Übersicht über die Probleme, die bei der Auswahl eines Gateways zu beachten sind:

  • 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 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. Dies wird in der Regel durch die Verwendung einer öffentlich oder privat routbaren IP-Adresse und eines Ports erreicht, die in ein Gateway aufgelöst werden. Clients außerhalb Ihres Mesh verwenden diese IP-Adresse und diesen Port, um Anfragen über Ihr Gateway an Dienste in Ihrem Mesh zu senden.

Cloud Load Balancing bietet verschiedene Load-Balancing-Optionen, die Sie als Gateway für Ihr Mesh verwenden können. Wenn Sie ein Google Cloud-Lastenausgleichsmodul 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?

Gateway für Ihr Mesh auswählen bietet eine Übersicht über die Cloud Load Balancing-Optionen, die vom Clientstandort und Kommunikationsprotokoll abhängen.

Traffic am Gateway verarbeiten

Da sich das Gateway am Rand des Mesh befindet – zwischen Clients außerhalb des Mesh und Diensten innerhalb des Mesh – ist das Gateway ein idealer Ort, um Richtlinien anzuwenden, wenn Traffic in das Mesh eintritt. Zu den Richtlinien gehören:

  • Trafficverwaltung (z. B. Routing, Weiterleitungen und Anfragetransformation)
  • Sicherheit (z. B. TLS-Beendigung und DDoS-Schutz von Google Cloud Armor)
  • Cloud CDN-Caching

Wenn Sie ein Gateway für Ihr Mesh auswählen, werden Richtlinien hervorgehoben, die am Rand Ihres Mesh relevant sind.

Traffic vom Gateway an einen Dienst in Ihrem Mesh senden

Nachdem Ihr Gateway Richtlinien auf eingehenden Traffic angewendet hat, entscheidet das Gateway, wohin der Traffic gesendet werden soll. Sie konfigurieren dies mithilfe von 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.

Ein Gateway für Ihr Mesh auswählen beschreibt die Back-Ends, an die ein Gateway Traffic senden kann.

Gateway für das Mesh 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.

Möglicherweise benötigen Sie nur eine Ebene, einen einzelnen Load-Balancer, der als Gateway für das Mesh 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 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 Traffic Director konfigurierten Gateways wird unter Gateway der zweiten Ebene am Rand des Mesh bereitstellen erläutert.

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
Internes HTTP(S)-Load-Balancing Google Cloud-basierte Clients in derselben Region wie der Load-Balancer

Lokale Clients, deren Anfragen in derselben Google Cloud-Region wie der Load-Balancer eingehen (z. B. über Cloud VPN oder Cloud Interconnect)
  • HTTP/1.1
  • HTTP/2
  • HTTPS
Erweiterte Trafficverwaltung
TLS-Beendigung mit selbstverwalteten Zertifikaten
Back-Ends in derselben Google Cloud-Region wie der Load-Balancer, ausgeführt auf:

VM-Back-Ends in Compute Engine

Containerinstanzen auf:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
HTTP(S)-Load-Balancing 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 für die Nutzerauthentifizierung
Back-Ends in einer beliebigen Google Cloud-Region, die auf

virtuellen Maschinen in Compute Engine-

Containerinstanzen ausgeführt werden auf:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Internes TCP/UDP-Load-Balancing Google Cloud-basierte Clients in jeder 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, die auf

virtuellen Maschinen in Compute Engine ausgeführt werden
Netzwerk-Load-Balancing Clients im öffentlichen Internet. Entweder TCP oder UDP Back-Ends in derselben Google Cloud-Region wie der Load-Balancer, die auf

virtuellen Maschinen in Compute Engine ausgeführt werden
SSL-Proxy-Load-Balancing und TCP-Proxy-Load-Balancing Clients im öffentlichen Internet. Entweder SSL oder TCP TLS-Beendigung mit Google- oder selbstverwalteten Zertifikaten (nur SSL-Proxy)

SSL-Richtlinien (nur SSL-Proxy)
Back-Ends in einer beliebigen Google Cloud-Region, die auf

virtuellen Maschinen in Compute Engine-

Containerinstanzen ausgeführt werden auf:
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Von Traffic Director 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 Gateway der zweiten Ebene am Rand des Mesh bereitstellen in diesem Dokument.
  • Sie können eine Anfrage über einen von Traffic Director konfigurierten Proxy senden, z. B. einen Sidecar-Proxy.
  • 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 einer beliebigen Google Cloud-Region, die auf

virtuellen Maschinen in Compute Engine-

Containerinstanzen ausgeführt werden auf:
  • Google Kubernetes Engine (GKE)
  • Kubernetes

Auf der Seite Funktionen des Load-Balancing-Moduls finden Sie einen detaillierten Funktionsvergleich. Auf den Traffic Director-Funktionsseiten finden Sie eine detaillierte Übersicht über die Traffic Director-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.

gcloud-Befehlszeilentool und Compute Engine APIs

Sie können zum Konfigurieren der verwalteten Load-Balancing-Produkte von Google Cloud und Traffic Director das gcloud-Befehlszeilentool und die Compute Engine APIs verwenden. Die Befehlszeile und die APIs bieten Mechanismen zum imperativen Bereitstellen und Konfigurieren Ihrer Google Cloud-Ressourcen. Sie können zum Automatisieren sich wiederholender Aufgaben Skripts erstellen.

Google Cloud Console

Sie können zum Konfigurieren von Traffic Director und der verwalteten Load-Balancer von Google Cloud die Google Cloud Console, eine grafische Benutzeroberfläche, verwenden. Zum Konfigurieren Ihres Gateway-Musters benötigen Sie wahrscheinlich sowohl die Cloud Load Balancing-Benutzeroberfläche als auch die Traffic Director-Benutzeroberfläche.

GKE und Multi-Cluster-Ingress

GKE- und Anthos-Netzwerkcontroller unterstützen auch die Bereitstellung von Cloud Load Balancing für die native 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 Traffic Director konfigurierte Dienste verweist, die in GKE-Clustern bereitgestellt werden.

Gateway-Architekturmuster

In diesem Abschnitt werden allgemeine Muster und Architekturdiagramme für Ihr Gateway beschrieben.

Muster

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 Traffic Director konfigurierten Edge-Proxy (oder Pool von Edge-Proxys).
    • Dieser Edge-Proxy fungiert als Gateway der zweiten Ebene. Diese Ebene:
      1. 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.
      2. Hiermit können Sie Richtlinien anwenden, die möglicherweise nicht von dem 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. Sowohl der übliche Fall als auch die erweiterten Muster werden unten beschrieben.

Eingehenden Traffic aus dem Internet aktivieren

Wenn sich Ihre 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.

Weitere Informationen zur Auswahl eines geeigneten Gateways finden Sie unter Gateway für Ihr Mesh auswählen.

Eingehender Traffic von Clients im öffentlichen Internet zu In-Mesh-Diensten mit einem Load-Balancer (zum Vergrößern klicken)
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 HTTP(S)-Load-Balancing 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
  • Cloud CDN zum Bereitstellen von Web- und Videoinhalten
  • Traffic-Management-Funktionen wie host- und wegebasiertes Routing

Eingehenden Traffic von Clients in Virtual Private Cloud und verbundenen lokalen Netzwerken aktivieren

Wenn sich Ihre Clients innerhalb Ihres VPC-Netzwerks befinden oder lokal sind und Google Cloud-Dienste über eine private Verbindungsmethode (z. B. Cloud VPN oder Cloud Interconnect) erreichen können, können Sie einen der folgenden Load-Balancer als Gateway verwenden.

Weitere Informationen zur Auswahl eines geeigneten Gateways finden Sie unter Gateway für Ihr Mesh auswählen.

Eingehender Traffic von Clients in einem VPC-Netzwerk zu In-Mesh-Diensten mithilfe eines Load-Balancers (zum Vergrößern klicken)
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 Internes HTTP(S) -Load-Balancing 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

Eingehenden Traffic mit einem Gateway der zweiten Ebene am Rand des Mesh 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 (zum Vergrößern klicken)
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 Traffic Director konfigurierter Edge-Proxy (oder Pool von Proxys), der sich hinter dem von Google Cloud verwalteten Lastenausgleichsmodul befindet. Sie können dieses Gateway der zweiten Ebene in Ihrem Projekt mithilfe eines Pools von Compute Engine-VMs (MIG) 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 HTTP(S) -Load-Balancing verwenden).

  • Der von Traffic Director 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 Traffic Director 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, die die von Traffic Director konfigurierten Gateways hosten. Informationen zu den von den einzelnen Load-Balancern unterstützten Back-Ends finden Sie unter Gateway für das Mesh auswählen. Informationen zur Nutzung von Traffic Director mit freigegebener VPC finden Sie unter Traffic Director mit freigegebener VPC auf mehreren GKE-Clustern konfigurieren.