Übersicht über serverlose Netzwerk-Endpunktgruppen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Back-End-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Back-End, das auf einen Cloud Run-, App Engine-, Cloud Functions oder API Gateway-Dienst verweist.

Eine serverlose NEG kann für eine der folgenden Dinge stehen:

  • Einen Cloud Run-Dienst oder eine Gruppe von Diensten.
  • Ein Cloud Functions-Feature oder eine Gruppe von Features.
  • Eine App Engine-Anwendung (Standard oder Flex), einen bestimmten Dienst innerhalb einer Anwendung, eine bestimmte Version einer Anwendung oder eine Gruppe von Diensten.
  • Ein API Gateway, das Zugriff auf Ihre Dienste über eine REST API bietet, die über alle Dienste hinweg unabhängig von der Dienstimplementierung konsistent ist. Diese Funktion befindet sich in der Vorschau.

Anwendungsfälle

Serverlose NEGs werden bei den folgenden Load-Balancern unterstützt:

Wenn Ihr HTTP(S)-Load-Balancer für serverlose Anwendungen aktiviert ist, haben Sie folgende Möglichkeiten:

  • Sie können Ihre serverlose Anwendung so konfigurieren, dass sie über eine dedizierte IPv4-IP-Adresse bereitgestellt wird, die nicht für andere Dienste freigegeben ist.
  • Sie können eine einzelne URL mehreren serverlosen Funktionen oder Diensten zuordnen, die in derselben Domain bereitgestellt werden. Siehe URL-Masken in diesem Dokument.
  • Geben Sie den URL-Speicherplatz für andere Google Cloud-Computing-Plattformen frei. Durch die Verwendung mehrerer Back-End-Dienste kann ein einzelner Load-Balancer Traffic an mehrere Back-End-Typen senden. Der Load-Balancer wählt den richtigen Back-End-Dienst anhand des Hosts oder Pfads der Anfrage-URL aus.
  • Sie können dieselben SSL-Zertifikate und privaten Schlüssel wiederverwenden, die Sie für Compute Engine, Google Kubernetes Engine und Cloud Storage verwenden. Wenn Sie dieselben Zertifikate wiederverwenden, müssen Sie keine separaten Zertifikate für serverlose Anwendungen verwalten.

Globaler externer HTTP(S)-Load-Balancer und globaler externer HTTP(S)-Load-Balancer (klassisch)

Das Einrichten eines globalen externen HTTP(S)-Load-Balancers oder eines globalen externen HTTP(S)-Load-Balancers (klassisch) ermöglicht die Einbindung Ihrer serverlosen Anwendungen in vorhandene Cloud-Dienste. In diesem Fall können Sie folgende Aufgaben ausführen:

  • Schützen Sie Ihren Dienst mit Google Cloud Armor, einem Edge-DDoS-Sicherheitsprodukt für alle Dienste, auf die über einen externen HTTP(S)-Load-Balancer zugegriffen wird. Für diese Funktion gibt es einige Einschränkungen, insbesondere für Cloud Run und App Engine.
  • Aktivieren Sie Ihren Dienst, um die Zustellung mithilfe von Cloud CDN zu optimieren. Cloud CDN speichert Inhalte in der Nähe der Nutzer im Cache. Cloud CDN bietet Funktionen wie Cache-Entwertung und Cloud CDN-signierte URLs.
  • Verwenden Sie die Edge-Infrastruktur von Google, um die HTTP(S)-Verbindungen des Nutzers näher am Nutzer zu beenden und so die Latenz zu verringern.

Informationen zum Konfigurieren eines Load-Balancers mit einem serverlosen Compute-Back-End finden Sie in der folgenden Dokumentation:

Durch die Einbindung des HTTP(S)-Load-Balancings in API Gateway können Ihre serverlosen Back-Ends alle Features von Cloud Load Balancing nutzen. Weitere Informationen finden Sie unter HTTP(S)-Load-Balancing für API Gateway. Informationen zum Konfigurieren des HTTP(S)-Load-Balancings zum Weiterleiten von Traffic an ein API-Gateway finden Sie unter Erste Schritte für das HTTP(S)-Load-Balancing für API Gateway. Diese Funktion befindet sich in der Vorschau.

Regionaler externer HTTP(S)-Load-Balancer

Mit einem regionalen externen HTTP(S)-Load-Balancer können Sie Arbeitslasten mit gesetzlichen oder Compliance-Anforderungen auf Cloud Run-Back-Ends ausführen. Wenn sich beispielsweise die Netzwerkkonfigurationen Ihrer Anwendung und die Traffic-Terminierung in einer bestimmten Region befinden müssen, ist ein regionaler externer HTTP(S)-Load-Balancer häufig die bevorzugte Option, um die erforderlichen gesetzlichen Anforderungen zu erfüllen.

Informationen zum Konfigurieren eines regionalen externen HTTP(S)-Load-Balancers mit einem serverlosen Compute-Back-End finden Sie unter Regionalen externen HTTP(S)-Load-Balancer mit Cloud Run einrichten.

Interner HTTP-Load-Balancer

Wenn das interne HTTP(S)-Load-Balancing mit Cloud Run-Back-Ends konfiguriert ist, können Sie:

  • Die erweiterten Features zur Trafficverwaltung des internen HTTP(S)-Load-Balancings für Ihre Cloud Run-Dienste aktivieren, z. B. Fehlerinjektion, Header-Überschreibungen, Weiterleitungen, Trafficaufteilung usw.
  • Legacy-Dienste nahtlos von Compute Engine, GKE oder lokal zu Cloud Run migrieren und die gewichtete Trafficaufteilung nutzen, um den Traffic ohne Ausfallzeiten schrittweise nach Cloud Run zu verlagern.
  • Ihre Cloud Run-Dienste mit VPC Service Controlsschützen.
  • Einen einzelnen Richtlinien-erzwingenden internen Eingangspunkt für Ihre Dienste einrichten, die in Cloud Run, Compute Engine und GKE ausgeführt werden.

Informationen zum Konfigurieren eines internen HTTP(S)-Load-Balancers mit einem serverlosen Compute-Back-End finden Sie unter Internen HTTP(S)-Load-Balancer mit Cloud Run einrichten.

Im weiteren Verlauf dieser Seite wird beschrieben, wie Sie serverlose NEGs mit HTTP(S)-Load-Balancern verwenden.

Weitere Informationen zu anderen Arten von NEGs finden Sie unter Übersicht über Netzwerk-Endpunktgruppen.

Endpunkttypen

Serverlose NEGs haben keine Netzwerkendpunkte wie Ports oder IP-Adressen. Sie können nur auf einen vorhandenen Cloud Run-, App Engine-, API Gateway- oder Cloud Functions-Dienst in derselben Region wie die NEG verweisen.

Wenn Sie eine serverlose NEG erstellen, geben Sie den vollqualifizierten Domainnamen (FQDN) des Cloud Run-, App Engine-, API Gateway- oder Cloud Functions-Dienstes an. Der Endpunkt hat den Typ SERVERLESS. Andere Endpunkttypen werden in einer serverlosen NEG nicht unterstützt.

Eine serverlose NEG kann nicht mehr als einen Endpunkt haben. Der Endpunkt verweist entweder auf eine serverlose Anwendung oder auf eine URL-Maske. Der Load-Balancer dient als Front-End für die serverlose Computing-Anwendung und leitet den Traffic an den angegebenen Endpunkt weiter. Wenn der Back-End-Dienst jedoch mehrere serverlose NEGs in verschiedenen Regionen enthält, sendet der Load-Balancer Traffic an die NEG in der Region, die geografisch am nächsten liegt, um die Anfragelatenz zu minimieren.

Netzwerkstufe

Für globale externe HTTP(S)-Load-Balancer können Sie eine serverlose NEG in einem Load-Balancer mit den Netzwerkdienststufen "Standard" oder "Premium" verwenden. Die Premium-Stufe ist nur erforderlich, wenn Sie serverlose NEGs in mehreren Regionen einrichten möchten.

Regionale externe HTTP(S)-Load-Balancer befinden sich immer in der Standardstufe.

Interne HTTP(S)-Load-Balancer befinden sich immer in der Premium-Stufe.

Load-Balancing-Komponenten

Ein Load-Balancer, der ein serverloses NEG-Back-End verwendet, erfordert eine spezielle Konfiguration nur für den Back-End-Dienst. Die Front-End-Konfiguration ist die gleiche wie bei jedem anderen proxybasierten Google Cloud-Load-Balancer. Darüber hinaus benötigen interne HTTP(S)-Load-Balancer ein Nur-Proxy-Subnetz, um Envoy-Proxys in Ihrem Namen auszuführen.

In den folgenden Diagrammen sehen Sie Beispiele für eine serverlose NEG-Bereitstellung.

Externes HTTP(S)

Dieses Diagramm zeigt, wie eine serverlose NEG in eine globale Architektur des externen HTTP(S)-Load-Balancers passt.

Globales externes HTTP(S)-Load-Balancing für serverlose Anwendungen
Globales externes HTTP(S)-Load-Balancing für serverlose Anwendungen

Dieses Diagramm zeigt, wie eine serverlose NEG in die Architektur eines regionalen externen HTTP(S)-Load-Balancers passt.

Regionales externes HTTP(S)-Load-Balancing für serverlose Anwendungen
Regionales externes HTTP(S)-Load-Balancing für serverlose Anwendungen

Internes HTTP(S)

Dieses Diagramm zeigt, wie eine serverlose NEG in das Modell des internen HTTP(S)-Load-Balancings passt.

Einfaches HTTPS-Load-Balancing (zum Vergrößern klicken)
Internes HTTP(S)-Load-Balancing für serverlose Anwendungen

Front-End-Komponenten

Für das Load-Balancing mit serverlosen NEG-Back-Ends ist keine spezielle Front-End-Konfiguration erforderlich. Weiterleitungsregeln werden verwendet, um Traffic nach IP-Adresse, Port und Protokoll an einen Zielproxy weiterzuleiten. Der Zielproxy beendet dann Verbindungen von Clients.

URL-Zuordnungen werden von HTTP(S)-Load-Balancern verwendet, um URL-basiertes Routing von Anfragen an die entsprechenden Back-End-Dienste einzurichten.

Weitere Informationen zu den einzelnen Komponenten finden Sie in den Architekturabschnitten der jeweiligen Load-Balancer-Übersicht:

Back-End-Dienst

Back-End-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Back-End-Dienst an einen oder mehrere verknüpfte Back-Ends weiter. Serverlose NEGs können als Back-Ends für bestimmte Load-Balancer verwendet werden.

An einen globalen Back-End-Dienst, der von globalen externen HTTP(S)-Load-Balancern verwendet wird, können mehrere serverlose NEGs angehängt werden, aber nur eine serverlose NEG pro Region. An einen regionalen Back-End-Dienst, der von internen HTTP(S)-Load-Balancern und regionalen externen HTTP(S)-Load-Balancern verwendet wird, kann nur eine einzelne serverlose NEG angehängt werden.

Jede serverlose NEG kann auf eine der folgenden Optionen verweisen:

  • FQDN für ein einzelnes Feature oder einen einzelnen Dienst
  • Eine URL-Maske, die auf mehrere Features oder Dienste verweist, die in derselben Domain bereitgestellt werden

Eine URL-Maske ist eine URL-Schemavorlage, die dem serverlosen NEG-Back-End mitteilt, wie die Nutzeranfrage dem richtigen Dienst zugeordnet werden soll. URL-Masken sind nützlich, wenn Sie eine benutzerdefinierte Domain für Ihre serverlose Anwendung verwenden und mehrere Dienste in derselben Domain bereitstellen. Anstatt für jede Funktion oder jeden Dienst eine separate serverlose NEG zu erstellen, können Sie die NEG mit einer generischen URL-Maske für die benutzerdefinierte Domain erstellen. Weitere Informationen und Beispiele finden Sie unter URL-Masken.

Weitere Einschränkungen beim Hinzufügen einer serverlosen NEG als Back-End finden Sie unter Einschränkungen.

URL-Masken

Ein serverloses NEG-Back-End kann entweder auf einen einzelnen Cloud Run-Dienst bzw. auf einen App Engine- oder Cloud Functions-Dienst (falls zutreffend) oder auf eine URL-Maske verweisen, die auf mehrere Dienste verweist. Eine URL-Maske ist eine Vorlage für Ihr URL-Schema. Die serverlose NEG verwendet diese Vorlage, um die Anfrage dem entsprechenden Dienst zuzuordnen.

URL-Masken sind eine optionale Funktion, mit der sich serverlose NEGs einfacher konfigurieren lassen, wenn Ihre serverlose Anwendung aus mehreren Cloud Run-, Cloud Functions- oder App Engine-Diensten besteht. Serverlose NEGs, die mit internen HTTP(S)-Load-Balancern verwendet werden, können nur eine URL-Maske verwenden, die auf Cloud Run-Dienste verweist.

URL-Masken sind nützlich, wenn Ihre serverlose Anwendung einer benutzerdefinierten Domain und nicht der von Google Cloud bereitgestellten Standardadresse zugeordnet ist. Mit einer benutzerdefinierten Domain wie example.com können Sie mehrere Dienste für verschiedene Subdomains oder Pfade in derselben Domain bereitstellen. In solchen Fällen können Sie anstelle eines separaten serverlosen NEG-Back-Ends für jeden Dienst eine einzelne serverlose NEG mit einer generischen URL-Maske für die benutzerdefinierte Domain erstellen (z. B. example.com/<service>). Die NEG extrahiert den Dienstnamen aus der Anfrage-URL.

Die folgende Abbildung zeigt einen externen HTTP(S)-Load-Balancer mit einem einzelnen Back-End-Dienst und einer serverlosen NEG, der eine URL-Maske verwendet, um Nutzeranfragen verschiedenen Diensten zuzuordnen.

Traffic auf serverlose Anwendungen verteilen (zum Vergrößern klicken)
URL-Maske verwenden, um Traffic auf verschiedene Dienste zu verteilen

URL-Masken funktionieren am besten, wenn die Dienste Ihrer Anwendung ein vorhersehbares URL-Schema verwenden. Der Vorteil der Verwendung einer URL-Maske anstelle einer URL-Zuordnung besteht darin, dass Sie keine separaten serverlosen NEGs für die Dienste login und search erstellen müssen. Außerdem müssen Sie die Konfiguration des Load-Balancers nicht jedes Mal ändern, wenn Sie Ihrer Anwendung einen neuen Dienst hinzufügen.

Informationen zum Erstellen und Konfigurieren einer URL-Maske für eine serverlose NEG finden Sie unter:

Beschränkungen

  • Eine serverlose NEG kann keine Netzwerkendpunkte wie IP-Adresse oder Port haben.
  • Serverlose NEGs können nur auf serverlose Anwendungen verweisen, die sich in derselben Region befinden, in der die NEG erstellt wird.
  • Für einen Load-Balancer, der ein serverloses NEG-Back-End verwendet, muss die serverlose NEG im selben Projekt erstellt werden wie die unterstützenden Cloud Run-, App Engine-, API Gateway- oder Cloud Functions-Dienste, auf die die NEG verweist. Möglicherweise schlagen Anfragen fehl, wenn Sie einen Dienst verbinden, der sich nicht im selben Projekt wie die serverlose NEG befindet.
  • Ein Load-Balancer, der mit einer serverlosen NEG konfiguriert ist, kann nicht erkennen, ob die zugrunde liegende serverlose Anwendung oder der zugrunde liegende Dienst wie erwartet funktioniert. Das bedeutet, dass der Load-Balancer weiterhin Traffic an den Dienst weiterleitet, auch wenn dieser Fehler zurückgibt. Testen Sie neue Versionen Ihrer Dienste gründlich, bevor Sie den Nutzertraffic an sie weiterleiten.

Einschränkungen bei Back-End-Diensten

Die folgenden Einschränkungen gelten für Back-End-Dienste mit einem serverlosen NEG-Back-End:

  • Ein globaler Back-End-Dienst kann pro Region eine serverlose NEG haben. Um mehrere serverlose NEGs in einem einzigen Back-End-Dienst zu kombinieren, müssen alle NEGs funktional äquivalente Bereitstellungen in verschiedenen Regionen darstellen. Die NEGs können beispielsweise auf denselben Cloud Run, App Engine- oder Cloud Functions-Dienst verweisen, der in verschiedenen Regionen bereitgestellt wird.
  • An einen regionalen Back-End-Dienst kann nur eine einzelne serverlose NEG angehängt werden.
  • Der Back-End-Dienst muss im selben Projekt erstellt werden wie die serverlose NEG und die entsprechenden Cloud Run-, App Engine-, API Gateway- oder Cloud Functions-Dienste. Wenn Sie eine freigegebene VPC-Bereitstellung mit projektübergreifendem Dienstverweis einrichten, können die Front-End-Komponenten des Load-Balancers (IP-Adresse, Weiterleitungsregel, Zielproxy und URL-Zuordnung) in einem anderen Projekt erstellt werden.
  • Die Einstellung für das Zeitlimit des Back-End-Dienstes gilt nicht für Back-End-Dienste mit serverlosen NEG-Back-Ends. Beim Versuch, das Attribut resource.timeoutSec des Back-End-Dienstes zu ändern, wird der folgende Fehler ausgegeben: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Für Back-End-Dienste mit serverlosen NEG-Back-Ends beträgt das Standardzeitlimit 60 Minuten. Dieses Zeitlimit kann nicht konfiguriert werden. Wenn Ihre Anwendung lang andauernde Verbindungen benötigt, konfigurieren Sie Ihre Clients so, dass sie bei einem Fehler Anfragen wiederholen.
  • Alle serverlosen NEGs, die in einem Back-End-Dienst kombiniert sind, müssen auch denselben Back-End-Typ verwenden. Das bedeutet, dass serverlose Cloud Run-NEGs nur mit anderen serverlosen Cloud Run-NEGs kombiniert werden können. Serverlose NEGs von App Engine können nur mit serverlosen NEGs von App Engine kombiniert werden usw.
  • Sie können serverlose NEGs nicht mit anderen Arten von NEGs (zonale oder Internet-NEGs) im selben Back-End-Dienst kombinieren. Beispielsweise können Sie nicht vom selben Back-End-Dienst an einen GKE-Cluster und einen Cloud Run-Dienst weiterleiten.
  • Beim Einrichten von Back-End-Diensten, die an serverlose NEGs weiterleiten, sind bestimmte Felder eingeschränkt:
    • Sie können keinen Balancing-Modus angeben. Das heißt, die Werte RATE, UTILIZATION und CONNECTION haben keine Auswirkungen auf die Trafficverteilung des Load-Balancers.
    • Systemdiagnosen werden für serverlose Back-Ends nicht unterstützt. Daher können Back-End-Dienste mit serverlosen NEG-Back-Ends nicht mit Systemdiagnosen konfiguriert werden.
  • Sie können den Befehl gcloud compute backend-services edit nicht verwenden, um einen Back-End-Dienst mit einem serverlosen NEG-Back-End zu ändern. Verwenden Sie stattdessen den Befehl gcloud compute backend-services update.

Je nach Typ des Load-Balancers und des serverlosen Back-Ends gelten weitere Einschränkungen.

Einschränkungen beim internen HTTP(S)-Load-Balancing

  • Serverlose NEGs, die mit internen HTTP(S)-Load-Balancern verwendet werden, können nur auf Cloud Run-Dienste verweisen.
  • Sie können die Google Cloud Console nicht verwenden, um einen internen HTTP(S)-Load-Balancer mit einem serverlosen NEG-Back-End einzurichten.
  • In Ihrem VPC-Netzwerk muss mindestens eine VM vorhanden sein, damit Sie einen internen HTTP(S)-Load-Balancer mit einem serverlosen Back-End einrichten können.

Einschränkungen bei regionalen externen HTTP(S)-Load-Balancern

  • Serverlose NEGs, die mit regionalen externen HTTP(S)-Load-Balancern verwendet werden, können nur auf Cloud Run-Dienste verweisen.
  • Sie können die Google Cloud Console nicht verwenden, um einen regionalen externen HTTP(S)-Load-Balancer mit einem serverlosen NEG-Back-End einzurichten.
  • In Ihrem VPC-Netzwerk muss mindestens eine VM vorhanden sein, damit Sie einen regionalen externen HTTP(S)-Load-Balancer mit einem serverlosen Back-End einrichten können.

Einschränkungen bei Cloud Run

  • Das externe HTTP(S)-Load-Balancing mit serverlosen NEGs wird mit Cloud Run for Anthos nicht unterstützt.
  • Das externe HTTP(S)-Load-Balancing unterstützt keine authentifizierten Anfragen an Cloud Run-Dienste.

Einschränkungen bei Cloud Functions

  • IAP funktioniert nicht mit Cloud Functions.

Einschränkungen bei App Engine

  • Multiregionales Load-Balancing wird von App Engine nicht unterstützt. Dies liegt daran, dass App Engine eine Region pro Projekt erfordert.
  • Im Anfragepfad ist nur eine IAP-Richtlinie zulässig. Wenn Sie beispielsweise bereits eine IAP-Richtlinie im Back-End-Dienst festgelegt haben, sollten Sie keine weitere IAP-Richtlinie in der App Engine-Anwendung festlegen.
  • Wir empfehlen die Verwendung von Steuerelementen für eingehenden Traffic, damit Ihre Anwendung nur Anfragen empfängt, die vom Load-Balancer (und ggf. von der VPC) gesendet werden. Andernfalls können Nutzer die App Engine-URL Ihrer Anwendung verwenden, um den Load-Balancer, die Google Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und private Schlüssel zu umgehen, die über den Load-Balancer weitergegeben werden.

Einschränkungen bei API Gateway

Weitere Informationen finden Sie unter Einschränkungen für serverlose NEGs und API Gateway.

Preise

Preisinformationen für Load-Balancer mit serverlosen NEGs finden Sie unter Netzwerkpreise.

Nächste Schritte