Ü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 Backend, 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.

Unterstützte Load-Balancer

In der folgenden Tabelle sind die serverlosen Produkte aufgeführt, die von jedem Application Load Balancer unterstützt werden. Serverlose NEGs werden von Proxy-Netzwerk-Load-Balancern und Passthrough-Netzwerk-Load-Balancern nicht unterstützt.

Serverlose Plattform Application Load Balancer
Regional
intern		 Regionenübergreifend,
intern		 Global
external		 Klassisch Regional
extern
Cloud Run
App Engine
Cloud Functions

Anwendungsfälle

Wenn Ihr 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 Backend-Dienste kann ein einzelner Load-Balancer Traffic an mehrere Backend-Typen senden. Der Load-Balancer wählt den richtigen Backend-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 Application Load Balancer und klassischer Application Load Balancer

Das Einrichten eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers 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 und einem WAF-Sicherheitsprodukt für alle Dienste, auf die über einen externen Application 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-Backend finden Sie in der folgenden Dokumentation:

Durch die Einbindung eines externen Application Load Balancers in API Gateway können Ihre serverlosen Back-Ends alle Features von Cloud Load Balancing nutzen. Weitere Informationen finden Sie unter Externer Application Load Balancer für API-Gateway. Informationen zum Konfigurieren eines externen Application Load Balancers zum Weiterleiten von Traffic an ein API-Gateway finden Sie unter Erste Schritte mit einem externen Application Load Balancer für API-Gateway. Diese Funktion befindet sich in der Vorschau.

Regionaler externer Application Load Balancer

Mit einem regionalen externen Application 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 Application Load Balancer häufig die bevorzugte Option, um die erforderlichen gesetzlichen Anforderungen zu erfüllen.

Informationen zum Konfigurieren eines regionalen externen Application Load Balancers mit einem serverlosen Compute-Backend finden Sie unter Regionalen externen Application Load Balancer mit Cloud Run einrichten.

Regionaler interner Application Load Balancer und regionenübergreifenden internen Application Load Balancer.

Wenn ein interner Application Load Balancer mit Cloud Run-Back-Ends konfiguriert ist, können Sie so vorgehen:

  • Die erweiterten Features zur Traffic-Verwaltung für Ihre Cloud Run-Dienste aktivieren, z. B. Fehlereinschleusung, Header-Umschreibungen, Weiterleitungen, Traffic-Aufteilung 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 regionalen internen Application Load Balancers mit einem serverlosen Compute-Backend finden Sie unter Regionalen internen Application Load Balancer mit Cloud Run einrichten.

Im weiteren Verlauf dieser Seite wird beschrieben, wie Sie serverlose NEGs mit Application 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 Frontend für die serverlose Computing-Anwendung und leitet den Traffic an den angegebenen Endpunkt weiter. Wenn der Backend-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 Application 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 Application Load Balancer befinden sich immer in der Standard-Stufe.

Regionenübergreifende interne Application Load Balancer und regionale interne Application Load Balancer befinden sich immer in der Premium-Stufe.

Load-Balancing-Komponenten

Ein Load-Balancer, der ein serverloses NEG-Backend verwendet, erfordert eine spezielle Konfiguration nur für den Backend-Dienst. Die Frontend-Konfiguration ist die gleiche wie bei jedem anderen proxybasierten Google Cloud-Load-Balancer. Darüber hinaus benötigen interne Application 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.

Global, extern

Dieses Diagramm zeigt, wie eine serverlose NEG in eine Architektur mit globalem externem Application Load Balancer passt.

Globaler externer Application Load Balancer für serverlose Anwendungen.
Globaler externer Application Load Balancer für serverlose Anwendungen (zum Vergrößern anklicken)

Regional, extern

Dieses Diagramm zeigt, wie eine serverlose NEG in eine Architektur mit regionalem externem Application Load Balancer passt.

Regionaler externer Application Load Balancer für serverlose Anwendungen.
Regionaler externer Application Load Balancer für serverlose Anwendungen (zum Vergrößern anklicken).

Regional intern

Dieses Diagramm zeigt, wie eine serverlose NEG in das Modell des regionalen internen Application Load Balancers passt.

Regionaler interner Application Load Balancer für serverlose Anwendungen.
Regionaler interner Application Load Balancer für serverlose Anwendungen (zum Vergrößern anklicken).

Regionenübergreifend

Dieses Diagramm zeigt, wie eine serverlose NEG in das regionenübergreifende Aplication Load Balancer-Modell passt.

Regionenübergreifender interner Application Load Balancer mit Cloud Run-Bereitstellung.
Regionenübergreifender interner Application Load Balancer mit Cloud Run-Bereitstellung (zum Vergrößern klicken).

Frontend-Komponenten

Für das Load-Balancing mit serverlosen NEG-Back-Ends ist keine spezielle Frontend-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 Application Load Balancern verwendet, um URL-basiertes Routing von Anfragen an die entsprechenden Backend-Dienste einzurichten.

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

Backend-Dienst

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

Die folgenden Einschränkungen gelten je nach Art des Load Balancers:

  • An einen globalen Backend-Dienst, der von globalen externen Application Load Balancern verwendet wird, können mehrere serverlose NEGs angehängt werden, aber nur eine serverlose NEG pro Region.
  • An einen regionalen Backend-Dienst, der von regionalen internen Application Load Balancern und regionalen externen Application Load Balancern verwendet wird, kann nur eine einzelne serverlose NEG angehängt werden.
  • An einen globalen Back-End-Dienst, der von regionenübergreifenden internen Application Load Balancern verwendet wird, können nur Cloud Run-Dienste 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-Backend 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 Backend finden Sie unter Einschränkungen.

Ausreißererkennung für serverlose NEGs

Die Ausreißererkennung ist eine optionale Konfiguration, die für einen globalen Backend-Dienst aktiviert werden kann, an den serverlose NEGs angehängt sind. Die Analyse der Ausreißererkennung ist nur für einen regionenübergreifenden internen Application Load Balancer, einen globalen externen Application Load Balancer und nicht für einen klassischen Application Load Balancer verfügbar. Die Analyse zur Ausreißererkennung identifiziert fehlerhafte serverlose NEGs anhand ihrer HTTP-Antwortmuster und reduziert die Fehlerquote, indem sie die meisten der neuen Anfragen von fehlerhaften Diensten an fehlerfreie Dienste weiterleitet. Informationen zur Funktionsweise des Ausreißeralgorithmus und zu den Einschränkungen finden Sie im folgenden Beispiel.

Angenommen, es ist ein Backend-Dienst mit zwei serverlosen NEGs angehängt, eine in der Region REGION_A und eine in der Region REGION_B. Wenn die serverlose NEG, die als Backend für einen globalen externen Application Load Balancer in der Region REGION_A dient, nicht reagiert, erkennt die Ausreißererkennung die serverlose NEG als fehlerhaft. Basierend auf der Analyse der Ausreißererkennung werden einige der neuen Anfragen dann an die serverlose NEG in der Region REGION_B gesendet.

Je nach Art des auftretenden Serverfehlers können Sie eine der folgenden Methoden zur Ausreißererkennung verwenden, um die Ausreißererkennung zu aktivieren:

  • Aufeinanderfolgende 5xx-Fehler. Der HTTP-Statuscode einer 5xx-Serie gilt als Fehler.
  • Aufeinanderfolgende Gateway-Fehler. Nur die HTTP-Statuscodes 502, 503 und 504 gelten als Fehler.

Beachten Sie, dass auch nach Aktivierung der Ausreißererkennung einige Anfragen wahrscheinlich an den fehlerhaften Dienst gesendet werden und somit 5XX-Fehler an die Clients zurückgegeben werden. Dies liegt daran, dass die Ergebnisse des Algorithmus zur Ausreißererkennung (Ausschluss von Endpunkten aus dem Load-Balancing-Pool und deren Rückführung in den Pool) von jeder Proxy-Instanz des Load Balancers unabhängig voneinander ausgeführt werden. In den meisten Fällen verarbeitet mehr als eine Proxy-Instanz den von einem Backend-Dienst empfangenen Traffic. Daher ist es möglich, dass ein fehlerhafter Endpunkt nur von einigen der Proxys erkannt und ausgeschlossen wird. In diesem Fall senden andere Proxys möglicherweise weiterhin Anfragen an denselben fehlerhaften Endpunkt.

Um die Fehlerraten weiter zu reduzieren, können Sie aggressivere Ausreißererkennungsparameter konfigurieren. Wir empfehlen, für die Ausschlussschwellenwerte (outlierDetection.baseEjectionTime) höhere Werte zu konfigurieren. Unsere Tests haben beispielsweise gezeigt, dass eine Einstellung von outlierDetection.baseEjectionTime auf 180 Sekunden mit einer kontinuierlichen Abfrage pro Sekunde von mehr als 100 zu einer Beobachtung von weniger als 5 % der Fehlerraten führt. Weitere Informationen zur Ausreißererkennungs-API finden Sie unter outlierDetection in der Dokumentation zur globalen Backend-Dienst-API.

Die folgenden outlierDetection-Felder werden nicht unterstützt, wenn an den Backend-Dienst eine serverlose NEG angehängt ist:

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

Informationen zum Konfigurieren der Ausreißererkennung finden Sie unter Globalen externen Application Load Balancer mit einem serverlosen Backend einrichten: Ausreißererkennung aktivieren.

URL-Masken

Ein serverloses NEG-Backend 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 Application 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 Application Load Balancer mit einem einzelnen Backend-Dienst und einer serverlosen NEG, der eine URL-Maske verwendet, um Nutzeranfragen verschiedenen Diensten zuzuordnen.

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

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.

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-Backend 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 Backend-Diensten

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

  • Ein globaler Backend-Dienst, der von globalen externen Application Load Balancern verwendet wird, kann pro Region nur eine serverlose NEG haben. Um mehrere serverlose NEGs in einem einzigen Backend-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 globalen Back-End-Dienst, der von regionenübergreifenden internen Application Load Balancern verwendet wird, kann nur ein Cloud Run-Dienst angehängt werden.
  • An einen regionalen Backend-Dienst kann nur eine einzelne serverlose NEG angehängt werden.
  • Der projektübergreifende Dienstverweis in einer freigegebenen VPC-Bereitstellung wird mit Konfigurationen unterstützt, die eine serverlose NEG enthalten. Erstellen Sie die Frontend-Komponenten des Load Balancers (IP-Adresse, Weiterleitungsregel, Zielproxy und URL-Zuordnung) in einem anderen Projekt als den Backend-Komponenten des Load Balancers (Backend-Dienst und serverlose NEGs), um diese Funktion zu verwenden. Beachten Sie, dass der Backend-Dienst, die zugehörigen serverlosen NEGs und der serverlose Dienst (Cloud Run, App Engine, API Gateway oder Cloud Functions) immer im selben Projekt erstellt werden müssen.
  • 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 Backend-Dienstes zu ändern, wird der folgende Fehler ausgegeben: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Für Backend-Dienste mit serverlosen NEG-Backends 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.
  • Sie können serverlose NEGs nicht mit anderen Arten von NEGs im selben Back-End-Dienst kombinieren. Beispielsweise können Sie nicht vom selben Backend-Dienst an einen GKE-Cluster und einen Cloud Run-Dienst weiterleiten.
  • When setting up backend services that route to serverless NEGs, certain fields are restricted:
    • 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 Backend-Dienste, die serverlose NEG-Backends enthalten, nicht mit Systemdiagnosen konfiguriert werden. Sie können jedoch optional die Ausreißererkennung aktivieren, um fehlerhafte serverlose Dienste zu identifizieren und neue Anfragen an einen fehlerfreien serverlosen Dienst weiterzuleiten.
  • Sie können den Befehl gcloud compute backend-services edit nicht verwenden, um einen Backend-Dienst mit einem serverlosen NEG-Backend 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 bei regionalen internen Application Load Balancern und regionalen externen Application Load Balancern

  • Serverlose NEGs, die mit regionalen internen Application Load Balancern oder regionalen externen Application Load Balancern verwendet werden, können nur auf Cloud Run-Dienste verweisen.
  • Bei Projekten, die serverlose NEGs verwenden, beträgt das Limit für die Abfragen pro Sekunde 5.000 QPS pro Projekt für Traffic, der an serverlose NEGs gesendet wird, die mit regionalen externen Application Load Balancern oder regionalen internen Application Load Balancern konfiguriert wurden. Dieses Limit wird für alle regionalen externen Application Load Balancer und regionalen internen Application Load Balancer im Projekt zusammengefasst. Dies ist kein Limit pro Load-Balancer.

Einschränkungen bei regionenübergreifenden internen Application Load Balancern

  • Serverlose NEGs, die mit regionenübergreifenden internen Application Load Balancern verwendet werden, können nur auf Cloud Run-Dienste verweisen.

Einschränkungen bei globalen externen Application Load Balancern

In diesem Abschnitt werden die Einschränkungen aufgeführt, die bei der Konfiguration serverloser NEGs mit globalen externen Anwendungs-Load-Balancern auftreten können.

Einschränkungen bei App Engine

  • Globale externe Application Load Balancer mit Back-Ends der flexiblen App Engine-Umgebung unterstützen keine projektübergreifende Dienstreferenz. App Engine-Standardumgebung wird unterstützt.

Einschränkungen bei Cloud Run

  • Ein externer Application Load Balancer mit serverlosen NEGs unterstützt Knative Serving nicht.
  • Externe Application Load Balancer unterstützen 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.

Einschränkungen bei Features zur Trafficverwaltung

  • Features zur erweiterten Trafficverwaltung wie Load-Balancing-Richtlinie für den Ort, Sitzungsaffinität und Ausreißererkennung werden für serverlose NEG-Back-Ends nicht unterstützt.
  • Die Angabe einer Sitzungsaffinität für einen Back-End-Dienst mit einem serverlosen NEG-Back-End funktioniert nicht. Verwenden Sie als Behelfslösung für Cloud Run das spezifische Sitzungsaffinitäts.

Preise

Preisinformationen für Load-Balancer mit serverlosen NEGs finden Sie unter Alle Netzwerkpreise: Cloud Load Balancing.

Nächste Schritte