Übersicht über serverlose Netzwerk-Endpunktgruppen

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- oder Cloud Functions-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.

Wenn das externe HTTP(S)-Load-Balancing für serverlose Anwendungen aktiviert ist, können Sie so vorgehen:

  • Konfigurieren Sie Ihre serverlose Anwendung so, dass sie von einer dedizierten IPv4- und/oder IPv6-IP-Adresse bereitgestellt wird, die nicht für andere Dienste freigegeben ist.
  • Ordnen Sie eine einzelne URL mehreren funktional identischen serverlosen Anwendungen zu. Durch die Ausführung der Anwendungen in verschiedenen Regionen können Anfragen an die Region weitergeleitet werden, die dem Nutzer am nächsten ist. Das Zuordnen einer einzelnen URL zu mehreren funktional identischen serverlosen Anwendungen wird nur für Cloud Run und Cloud Functions unterstützt.
  • 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.

Wenn Sie HTTP(S)-Load-Balancing einrichten, können Ihre serverlosen Anwendungen auch in vorhandene Cloud-Dienste integriert werden. In diesem Fall können Sie folgende Aktionen ausführen:

  • Geben Sie den URL-Speicherplatz für andere Google Cloud-Technologien frei. Durch die Verwendung mehrerer Back-End-Dienste kann ein einziger externer HTTP(S)-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.
  • 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.

Im Rest dieses Dokuments wird die Verwendung serverloser NEGs (Netzwerk-Endpunktgruppen) mit externen HTTP(S)-Load-Balancern erläutert. Sie können serverlose NEGs nicht mit regionalen externen HTTP(S)-Load-Balancern oder mit anderen Load-Balancer-Typen verwenden.

Weitere Informationen zu anderen Arten von NEGs finden Sie unter:

Endpunkttypen

Serverlose NEGs haben keine Netzwerkendpunkte wie Ports oder IP-Adressen. Sie können nur auf einen vorhandenen Cloud Run-, App Engine- 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- 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. Da in jeder serverlosen NEG nur ein Endpunkt zulässig ist, dient der Load-Balancer nur als Front-End und leitet den Traffic an den angegebenen serverlosen Endpunkt weiter. Wenn der Back-End-Dienst jedoch mehrere serverlose NEGs enthält, verteilt der Load-Balancer den Traffic zwischen diesen NEGs und minimiert so die Anfragelatenz.

Netzwerkstufe

Sie können 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.

Load-Balancing-Komponenten

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

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

Weiterleitungsregel

Die Weiterleitungsregel ist Teil der Front-End-Konfiguration. Jede Weiterleitungsregel hat eine externe IP-Adresse, die IP-Version (IPv4 oder IPv6), ein Protokoll (HTTP oder HTTPS, einschließlich HTTP/2) und eine Portnummer (80 oder 443)

Zielproxy

Serverlose NEGs können nur mit HTTP- und HTTPS-Zielproxys verwendet werden. Dienste, die serverlose NEGs verwenden, können nicht mit TCP- oder SSL-Zielproxys verwendet werden.

URL-Zuordnung

Die Auswahl für die Weiterleitung für einen externen HTTP(S)-Load-Balancer erfolgt auf der Grundlage einer URL-Zuordnung. Bei einer URL-Zuordnung bestimmen Ziel-HTTP(S)-Proxys den zu verwendenden Back-End-Dienst, indem sie den Hostnamen und den Pfad der Anfrage in der URL-Zuordnung überprüfen. Load-Balancer können mehrere Back-End-Dienste haben, auf die von der URL-Zuordnung verwiesen wird. Jeder Back-End-Dienst kann einem anderen Back-End-Typ zugeordnet werden. Sie können beispielsweise einen Back-End-Dienst für eine serverlose NEG und einen anderen Back-End-Dienst für Compute Engine-Instanzgruppen haben.

Back-End-Dienst

Serverlose NEGs können als Back-Ends in einem Load-Balancer verwendet werden. Ein Back-End-Dienst kann mehrere serverlose NEGs haben. 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 Anwendung verwenden und mehrere Cloud Run-, Cloud Functions- oder App Engine-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

Optionale URL-Masken erleichtern die Konfiguration serverloser NEGs, wenn Ihre Anwendung mehrere Cloud Run-, Cloud Functions- oder App Engine-Dienste hat. Ein serverloses NEG-Back-End kann entweder auf einen einzelnen Cloud Run- (oder App Engine- oder Cloud Functions-)Dienst verweisen oder auf eine URL-Maske, 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 Service zuzuordnen.

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 HTTP(S)-Load-Balancer mit einer serverlosen NEG einrichten.

Beschränkungen

  • Sie können keine serverlosen NEGs als Back-Ends für regionale externe HTTP(S)-Load-Balancer verwenden.
  • Eine serverlose NEG kann keine Netzwerkendpunkte wie IP-Adresse oder Port haben.
  • Serverlose NEGs können nur auf Cloud Run-, App Engine- oder Cloud Functions-Dienste verweisen, die sich in derselben Region befinden, in der die NEG erstellt wird.
  • Load-Balancer, die serverlose NEG-Back-Ends verwenden, müssen im selben Projekt erstellt werden wie die Cloud Run-, App Engine- oder Cloud Functions-Dienste, auf die die NEG verweist.
  • Ein externer HTTP(S)-Load-Balancer, der mit einer serverlosen NEG konfiguriert ist, kann nicht erkennen, ob der zugrunde liegende Dienst wie erwartet funktioniert. Dies bedeutet, dass Ihr externer HTTP(S)-Load-Balancer den Traffic nicht automatisch in andere Regionen weiterleiten kann, wenn Ihr Dienst in einer Region Fehlermeldungen ausgibt, aber die gesamte Infrastruktur in dieser Region normal funktioniert. Testen Sie neue Versionen Ihrer Dienste gründlich, bevor Sie den Nutzertraffic an sie weiterleiten.

Einschränkungen für Back-End-Dienste mit einem serverlosen NEG-Back-End

  • Ein 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.
  • 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.
  • 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 Cloud Run serverlosen NEGs kombiniert werden können. Serverlose NEGs von App Engine können nur mit serverlosen NEGs von App Engine kombiniert werden etc.
  • 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.

Abhängig von der verwendeten serverlosen Computing-Plattform können zusätzliche Einschränkungen gelten.

Einschränkungen bei Cloud Run

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

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.

Preise

Informationen zu Preisen für externe HTTP(S)-Load-Balancer mit serverlosen NEGs finden Sie unter Netzwerkpreise.

Nächste Schritte