Ü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 Folgendes darstellen:

  • Einen Cloud Run-Dienst oder eine Gruppe von Diensten mit demselben URL-Muster
  • Eine Cloud Functions-Funktion oder eine Gruppe von Funktionen mit demselben URL-Muster
  • Eine App Engine-Anwendung (Standard oder Flex), einen bestimmten Dienst innerhalb einer Anwendung oder sogar eine bestimmte Version einer Anwendung.

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

  • 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 Diensten zu, die in verschiedenen Regionen ausgeführt werden, sodass Anfragen an die Region weitergeleitet werden können, die dem Nutzer am nächsten ist. Dies wird nur für Cloud Run (vollständig verwaltet) unterstützt.
  • Verwenden Sie dieselben SSL-Zertifikate und privaten Schlüssel wieder, die Sie für Compute Engine, Google Kubernetes Engine und Cloud Storage verwenden. Dadurch müssen keine separaten Zertifikate für serverlose Anwendungen verwaltet werden.

Wenn Sie HTTP(S)-Load-Balancing einrichten, können Ihre serverlosen Anwendungen auch in vorhandene Cloud-Dienste integriert werden. Sie haben folgende Möglichkeiten:

  • 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 basierend auf dem Host oder Pfad der Anfragen-URL an Cloud Run (vollständig verwaltet), App Engine, Cloud Functions, Compute Engine, Google Kubernetes Engine und Cloud Storage senden.
  • 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. Beachten Sie, dass mit dieser Funktion einige Einschränkungen verbunden sind, insbesondere für Cloud Run (vollständig verwaltet) und App Engine.
  • Aktivieren Sie Ihren Dienst, um die Zustellung mithilfe von Cloud CDN zu optimieren. Mit Cloud CDN können Sie Inhalte in der Nähe Ihrer Nutzer im Cache speichern. 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 mit HTTP(S)-Load-Balancing erläutert. Serverlose NEGs können nicht mit anderen Load-Balancer-Typen verwendet werden.

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 (vollständig verwaltet), 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 (vollständig verwaltet)-, 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

So passt eine serverlose NEG in das HTTP(S)-Load-Balancing-Modell.

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 und enthält 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 für Back-End-Dienste in einem Load-Balancer verwendet werden. Ein Back-End-Dienst kann von mehreren serverlosen NEGs unterstützt werden, aber jede serverlose NEG kann nur auf den FQDN für einen einzelnen Cloud Run (vollständig verwaltet)-, App Engine- oder Cloud Functions-Dienst verweisen oder auf eine URL-Maske, die auf mehrere Dienste in derselben Domain verweist.

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 (vollständig verwaltet)-, Cloud Functions- oder App Engine-Dienste in derselben Domain bereitstellen. In solchen Fällen können Sie anstelle einer separaten serverlosen NEG für jeden Cloud Run (vollständig verwaltet)-, App Engine- oder Cloud Functions-Dienst die NEG mit einer generischen URL-Maske für die benutzerdefinierte Domain (z. B. example.com/<service>) erstellen und zulassen, dass die NEG den Dienstnamen aus der URL der Anfrage extrahiert. Weitere Informationen und Beispiele finden Sie unter URL-Masken.

Wenn Sie eine serverlose NEG als Back-End hinzufügen, müssen Sie zusätzliche Einschränkungen beachten. Weitere Informationen finden Sie unter Einschränkungen.

URL-Masken

URL-Masken sind eine optionale Funktion, mit der sich serverlose NEGs einfacher konfigurieren lassen, wenn Ihre Anwendung aus mehreren Cloud Run (vollständig verwaltet)-, Cloud Functions- oder App Engine-Diensten besteht. Ein serverloses NEG-Back-End kann entweder auf einen einzelnen Cloud Run (vollständig verwaltet)- (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 (z. B. example.com/<service>), um den Dienstnamen aus der URL der eingehenden Anfrage zu extrahieren und die Anfrage dem entsprechenden Dienst 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 Cloud Run (vollständig verwaltet)-, Cloud Functions- oder App Engine-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 Cloud Run (vollständig verwaltet)-, App Engine- oder Cloud Functions-Dienst eine einzelne serverlose NEG mit einer generischen URL-Maske für die benutzerdefinierte Domain (z. B. example.com/<service>) erstellen und zulassen, dass die NEG den Dienstnamen aus der URL der Anfrage extrahiert.

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 Serverlose NEGs einrichten.

Beschränkungen

  • Mit der Google Cloud Console können Sie keine serverlose NEG erstellen. Verwenden Sie entweder das gcloud-Befehlszeilentool oder die API. Informationen zum Konzept und zur Installation des Tools finden Sie unter Übersicht zu gcloud.
  • Eine serverlose NEG kann keine Netzwerkendpunkte wie IP-Adresse oder Port haben.
  • Serverlose NEGs können nur auf Cloud Run (vollständig verwaltet)-, 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 (vollständig verwaltet)-, App Engine- oder Cloud Functions-Dienste, auf die die NEG verweist.
  • Cloud Monitoring wird für serverlose NEG-Back-Ends nicht unterstützt. Back-End-Dienste mit anderen Back-End-Typen sind nicht betroffen.
  • Ein externer HTTP(S)-Load-Balancer, der mit einer serverlosen NEG konfiguriert ist, kann nicht erkennen, ob die zugrunde liegende serverlose Ressource (z. B. ein App Engine-, Cloud Functions- oder Cloud Run (vollständig verwaltet)-Dienst) erwartungsgemäß funktioniert. Dies bedeutet, dass Ihr externer HTTP(S)-Load-Balancer den Traffic nicht automatisch in andere Regionen weiterleitet, wenn Ihr Dienst in einer Region Fehlermeldungen ausgibt, aber die gesamte (vollständig verwaltete) Cloud Run-, Cloud Functions- oder App Engine-Infrastruktur in dieser Region ordnungsgemäß funktioniert. Testen Sie neue Versionen Ihrer Dienste gründlich, bevor Sie den Nutzer-Traffic an sie weiterleiten.

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

  • Ein Back-End-Dienst darf pro Region nur eine serverlose NEG enthalten. Wenn Sie mehrere serverlose NEGs in einem einzigen Back-End-Dienst kombinieren möchten, müssen alle NEGs funktional äquivalente Bereitstellungen in verschiedenen Regionen darstellen. Die NEGs können beispielsweise auf denselben Cloud Run- (vollständig verwaltet), App Engine- oder Cloud Functions-Dienst verweisen, der in verschiedenen Regionen bereitgestellt wird.
  • Das standardmäßige Back-End-Dienst-Zeitlimit von 30 Sekunden eines serverlosen NEG-Back-End-Dienstes kann nicht geändert werden. Der Versuch, die Back-End-Dienstkonfiguration zu ändern, um das Zeitlimit (durch Festlegen des Attributs resource.timeoutSec) zu erhöhen, führt zu folgendem Fehler: 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 (vollständig verwaltet)-NEGs nur mit anderen Cloud Run (vollständig verwaltet)-NEGs kombiniert werden können.
  • Sie können serverlose NEGs nicht mit anderen Arten von NEGs (zonale oder Internet-NEGs) im selben Back-End-Dienst kombinieren. Dies bedeutet beispielsweise, dass Sie nicht vom selben Back-End-Dienst an einen GKE-Cluster und einen (vollständig verwalteten) Cloud Run-Dienst weiterleiten können.
  • 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.
  • Das Entfernen aller serverlosen NEGs aus einem Back-End-Dienst führt nicht automatisch zu 502 Bad Gateway-Antworten für Nutzer. Nutzer sehen HTTP-200 OK-Antworten weiterhin, auch wenn alle serverlosen NEG-Back-Ends aus einem Back-End-Dienst entfernt wurden. Um dies zu ändern, müssen Sie den Traffic an den Back-End-Dienst beenden.

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

Einschränkungen bei Cloud Run (vollständig verwaltet)

  • Identity-Aware Proxy (IAP) funktioniert nicht mit Cloud Run (vollständig verwaltet).
  • Sie können die URLs, die Google Cloud automatisch (vollständig verwalteten) Cloud Run-Diensten zuweist, nicht deaktivieren. Nutzer, die bereits die Standard-URL des (vollständig verwalteten) Cloud Run-Dienstes haben, können den Load-Balancer umgehen und direkt zur Dienst-URL wechseln. Dies bedeutet, dass Nutzer mit der Standard-URL diese Richtlinien umgehen können, auch wenn Sie Google Cloud Armor-Sicherheitsrichtlinien über den Load-Balancer konfigurieren können.
  • Wenn Sie die serverseitige gRPC-Streaming-API in Cloud Run (vollständig verwaltet) verwenden, führen Anfragen, die länger als 30 Sekunden dauern, zu einer RST_STREAM-Meldung.

Einschränkungen bei Cloud Functions

  • IAP funktioniert nicht mit Cloud Functions.
  • Sie können die URLs, die Google Cloud den Cloud Functions-Funktionen automatisch zuweist, nicht deaktivieren. Sie können jedoch die internal-and-gclb-Einstellung für eingehenden Traffic verwenden, um nur internen Traffic und Traffic zuzulassen, der vom externen HTTP(S)-Load-Balancer an eine öffentliche IP-Adresse gesendet wird. Traffic, der an cloudfunctions.net oder eine andere benutzerdefinierte, über Cloud Functions eingerichtete Domain gesendet wird, wird blockiert. Dadurch wird verhindert, dass Nutzer Zugriffskontrollen (z. B. Google Cloud Armor-Sicherheitsrichtlinien) umgehen, die über den externen HTTP(S)-Load-Balancer eingerichtet wurden.

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.

  • Sie können die URLs, die Google Cloud App Engine-Diensten automatisch zuweist, nicht deaktivieren. Nutzer, die bereits die Standard-URL des App Engine-Dienstes haben, können den Load-Balancer umgehen und direkt zur Dienst-URL wechseln. Dies bedeutet, dass Nutzer mit der Standard-URL diese Richtlinien umgehen können, auch wenn Sie Google Cloud Armor-Sicherheitsrichtlinien über den Load-Balancer konfigurieren können.

Preise

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

Weitere Informationen