Internetnetzwerk-Endpunktgruppen

Cloud Load Balancing unterstützt die Proxy-Weiterleitung von Traffic zu externen Back-Ends außerhalb von Google Cloud. Zum Definieren eines externen Back-Ends für einen Load Balancer verwenden Sie eine Ressource, die als Internet-NEG (Netzwerk-Endpunktgruppe) bezeichnet wird.

Sie können diese Art der Bereitstellung verwenden, wenn Sie Inhalte von einem externen Backend bereitstellen, aber der Google Cloud-Load-Balancer das Frontend sein soll. Sie haben dann folgende Möglichkeiten:

  • Verwenden Sie die Google Edge-Infrastruktur, um Ihre Nutzerverbindungen zu beenden.
  • Leiten Sie die Verbindungen zu Ihrem externen Back-End weiter.
  • Stellen Sie Traffic zu Ihrem öffentlichen Endpunkt über den privaten Backbone von Google bereit. So steigern Sie die Zuverlässigkeit und verringern die Latenz zwischen Client und Server.
  • Mit globalen Load Balancern können Sie mit Cloud CDN Inhalte für Ihr externes Backend im Cache speichern.

Abbildung 1 zeigt einen externen Application Load Balancer mit mehreren Backend-Typen, von denen einer ein externes Backend ist, das mit einer Internet-NEG konfiguriert ist.

Internetnetzwerk-Endpunktgruppen im Load-Balancing.
Abbildung 1. Internetnetzwerk-Endpunktgruppen im Load-Balancing (zum Vergrößern klicken).

Internet-NEG-Back-Ends werden von verschiedenen globalen und regionalen Load Balancern unterstützt. Je nach globalem oder regionalem Load Balancer variiert die Unterstützung der Internet-NEG in Bezug auf DNS, Systemdiagnose, verfügbare Endpunkte und Traffic-Routingverhalten.

In den folgenden Abschnitten wird erläutert, wie externe Backends mit Cloud Load Balancing verwendet werden. Informationen zum Verwenden eines externen Backends mit Cloud Service Mesh finden Sie unter Cloud Service Mesh mit Internetnetzwerk-Endpunktgruppen.

Terminologie

Die folgenden Begriffe werden manchmal synonym verwendet, da sie dieselbe oder eine ähnliche Bedeutung haben:

  • Externes Back-End: Ein Back-End, das sich außerhalb von Google Cloud befindet und über das Internet erreichbar ist. Der Endpunkt in einer Internet-NEG.
  • Benutzerdefinierter Ursprung: Entspricht einem externen Back-End. Im CDN ist Ursprung der in der Branche übliche Begriff für eine Back-End-Instanz, die Webinhalte bereitstellt.
  • Internetnetzwerk-Endpunktgruppe (NEG): Die Google Cloud API-Ressource, mit der Sie ein externes Back-End angeben.
  • Externer Endpunkt: Entspricht einem externen Back-End.

In diesem Dokument wird der Begriff externes Backend verwendet, außer bei Bezug auf die Internet-NEG-API-Ressource.

Komponenten des Lastenausgleichsmoduls

In diesem Abschnitt werden die Load-Balancing-Architektur und die Ressourcen beschrieben, die zum Konfigurieren eines Load-Balancers mit einem externen Backend erforderlich sind. Der Load-Balancer erfordert spezifische Konfiguration nur für den Backend-Dienst. Die Frontend-Konfiguration ist die gleiche wie für jeden anderen Load Balancer.

Die folgenden Abbildungen zeigen die Google Cloud-Ressourcen, die zum Einrichten eines Load Balancers mit einem externen Backend erforderlich sind.

Global, extern

Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines globalen externen Application Load Balancers mit einem externen Backend erforderlich sind.

Globaler externer Application Load Balancer mit externem Backend.
Global external Application Load Balancer with external backend (click to enlarge).

Regional, extern

Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen externen Application Load Balancers mit einem externen Backend erforderlich sind.

Globaler externer Application Load Balancer mit externem Backend.
Regional external Application Load Balancer with an external backend (click to enlarge).

Regional intern

Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen internen Application Load Balancers mit einem externen Backend erforderlich sind.

Regionaler interner Application Load Balancer mit einem externen Backend.
Regional internal Application Load Balancer with an external backend (click to enlarge).

Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen internen Proxy-Network Load Balancer mit einem externen Backend erforderlich sind.

Regionaler interner Proxy-Network Load Balancer mit einem externen Backend.
Regional internal proxy Network Load Balancer with an external backend (click to enlarge).

Sie können Internet-NEGs nur auf der Premium-Netzwerkdienststufe verwenden.

Frontend-Konfiguration

Zum Erstellen eines Load-Balancers mit einem Internet-NEG-Backend 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. Darüber hinaus benötigen Envoy-basierte Load Balancer ein Nur-Proxy-Subnetz.

Application Load Balancer verwenden auch URL-Zuordnungen, um ein URL-basiertes Routing von Anfragen an die entsprechenden Backend-Dienste einzurichten.

Weitere Informationen zu den einzelnen Komponenten finden Sie in den Architekturabschnitten des jeweiligen Load Balancers:

Internet-NEG

Eine Internet-NEG ist eine globale Ressource, mit der ein externes Backend für den Load Balancer definiert wird. Das externe Backend, auf das von der Internet-NEG verwiesen wird, muss über das Internet erreichbar sein. Der Endpunkt darf nicht nur über Cloud VPN oder Cloud Interconnect erreichbar sein. Wenn das externe Backend auf eine Google-API oder einen Google-Dienst verweist, muss der Dienst über den TCP-Port 80 oder 443 über das HTTP-, HTTPS- oder HTTP/2-Protokoll erreichbar sein.

Es gibt zwei Möglichkeiten, den externen Endpunkt zu konfigurieren, auf den die NEG verweist: INTERNET_FQDN_PORT oder INTERNET_IP_PORT. Außerdem sind all diese Endpunkte in zwei Bereichen verfügbar: global oder regional.

Globale Internet-NEGs basieren auf GFE-Technologien (Google Front End). Sie verwenden eine feste Anzahl fester IP-Adressen für ausgehenden Traffic an alle Clients. Sie unterstützen nur einen Endpunkt pro NEG und eine Internet-NEG pro Back-End-Dienst.

In der folgenden Tabelle wird beschrieben, wie verschiedene Load Balancer globale Internet-NEGs unterstützen.

Load-Balancer Endpunkttyp Endpunktdefinition Umfang Systemdiagnosen
  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer

INTERNET_FQDN_PORT

Ein öffentlich auflösbarer, voll qualifizierter Domainname und ein optionaler Port. Zum Beispiel backend.example.com:443†.

Der Domainname muss durch die öffentliche DNS-Infrastruktur von Google aufgelöst werden können.

Pro NEG ist nur ein Endpunkt zulässig.

 Global Nicht unterstützt

INTERNET_IP_PORT

Eine öffentlich weiterleitbare IP-Adresse und ein optionaler Port. Zum Beispiel: 8.8.8.8:4431.

Die IP-Adresse darf keine RFC 1918-Adresse sein.

Pro NEG ist nur ein Endpunkt zulässig.

† Wenn Sie beim Hinzufügen des Endpunkts keinen Port angeben, wird der Standardport der NEG verwendet. Wenn Sie keinen Standardport für die NEG angegeben haben, wird der bekannte Port für Ihr Backend-Protokoll verwendet (80 für HTTP und 443 für HTTPS und HTTP/2).

Regionale Internet-NEGs werden von verwalteten Envoy-Proxys und Cloud NAT-Gateways unterstützt. Sie unterstützen mehrere Endpunkte pro NEG und mehrere Internet-NEGs pro Back-End-Dienst. IP-Adressen, die für ausgehenden Traffic an Clients verwendet werden, können mit Cloud NAT-Gateways konfiguriert werden.

In der folgenden Tabelle wird beschrieben, wie verschiedene Load Balancer regionale Internet-NEGs unterstützen.

Load-Balancer Endpunkttyp Endpunktdefinition Umfang Systemdiagnosen
  • Regionaler externer Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Regionaler externer Proxy-Network Load Balancer
  • Regionaler interner Proxy-Network Load Balancer

INTERNET_FQDN_PORT

Ein öffentlich auflösbarer, voll qualifizierter Domainname und ein optionaler Port. Zum Beispiel backend.example.com:443*.

Der Domainname muss entweder über Cloud DNS oder über die öffentliche DNS-Infrastruktur von Google aufgelöst werden können.

Pro NEG sind maximal 256 Endpunkte zulässig.

 Regional Verteilte Envoy-Systemdiagnosen

INTERNET_IP_PORT

Eine öffentlich weiterleitbare IP-Adresse und ein optionaler Port. Beispiel: 8.8.8.8:4432.

Die IP-Adresse darf keine RFC 1918-Adresse sein.

Pro NEG sind maximal 256 Endpunkte zulässig.

* Bei regionalen Internet-NEGs müssen Sie einen Port angeben. Sie können beim Erstellen der NEG einen Standardport angeben oder jedes Mal einen Port angeben, wenn Sie einen Endpunkt zu der NEG hinzufügen, oder Sie können beides tun. Wenn Sie beim Hinzufügen eines Endpunkts keinen Port angeben, wird der Standardport der NEG verwendet.

DNS-Auflösung für regionale INTERNET_FQDN_PORT-Endpunkte

Wenn Ihre Domain über das Internet aufgelöst werden kann, ist keine weitere Konfiguration erforderlich, um DNS einzurichten. Wenn Sie jedoch private FQDNs auflösen, müssen Sie Cloud DNS konfigurieren, um die DNS-Auflösung zu ermöglichen. Der Name muss in Cloud DNS gehostet werden oder mithilfe der DNS-Weiterleitung von Cloud DNS zu einem lokalen DNS aufgelöst werden können.

Erstellen Sie zuerst eine Cloud DNS-Zone, um die DNS-Einträge in Ihrem Projekt zu hosten. Fügen Sie dann die DNS-Einträge hinzu. Informationen zu spezifischen Konfigurationsschritten finden Sie in der Cloud DNS-Dokumentation.

Wenn Sie eine freigegebene VPC verwenden, beachten Sie die spezifischen Netzwerkanforderungen. Sie können auch andere Features von Cloud DNS wie Weiterleitungszonen verwenden, um Einträge von einem lokalen DNS-Server abzurufen.

Auflösung der IP-Adresse für globale INTERNET_FQDN_PORT-Endpunkte

Wenn ein INTERNET_FQDN_PORT-Endpunkt auf einen DNS-Eintrag verweist, der mehrere IP-Adressen zurückgibt, wird die IP-Adresse so aufgelöst:

  • Der Load-Balancer verwendet einen DNS-Resolver in einer Google Cloud-Region, die dem Client im Internet am nächsten ist. Wenn der DNS-Eintrag für den INTERNET_FQDN_PORT-Endpunkt unterschiedliche IP-Adressen abhängig vom Standort des Clients zurückgibt, achten Sie darauf, dass jede dieser IP-Adressen vom Load-Balancer erreicht werden kann.

  • Der Load-Balancer versucht, eine Verbindung zur ersten IP-Adresse in der DNS-Antwort herzustellen. Wenn diese IP-Adresse nicht erreichbar ist, gibt der Load-Balancer die HTTP-Antwort 502 (Bad Gateway) zurück. Dies gilt auch, wenn andere IP-Adressen aus der DNS-Antwort verfügbar sind.

Weitere Informationen zu den IP-Bereichen und Standorten, die von der DNS-Resolver-Infrastruktur von Google verwendet werden, finden Sie in der Dokumentation zu Google Public DNS. Namen, die vom öffentlichen DNS-System nicht aufgelöst werden können, können nicht als externe Back-Ends verwendet werden.

Auflösung der IP-Adresse für regionale INTERNET_FQDN_PORT-Endpunkte

Regionale Internet-NEGs unterstützen die Auflösung von Domainnamen sowohl mit Cloud DNS als auch mit dem öffentlichen DNS von Google. Bei öffentlichen DNS-Servern leitet Cloud DNS den Traffic an öffentliche DNS-Server weiter.

Wenn der DNS-Server mehrere IP-Adressen zurückgibt, verteilt Envoy den Traffic zwischen den zurückgegebenen IP-Adressen anhand des konfigurierten Load Balancing-Algorithmus (Round Robin, letzte Anfrage usw.). Die Liste der Endpunkte wird regelmäßig basierend auf der DNS-TTL aktualisiert. Sie können Wiederholungsrichtlinien konfigurieren, um Envoy zu zwingen, eine Verbindung zu einer anderen IP-Adresse herzustellen, wenn eine fehlschlägt.

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.

Um einen Load-Balancer mit einem externen Backend einzurichten, konfigurieren Sie den Backend-Dienst mit einem Internet-NEG-Backend. Wenn Sie einem Backend-Dienst eine Internet-NEG hinzufügen, gelten je nach Umfang der NEG die folgenden Überlegungen:

  • Der Backend-Dienst kann nicht auch andere Backend-Typen wie zonale NEGs oder Instanzgruppen als Backends verwenden.

  • Anzahl der NEGs pro Back-End-Dienst

    • Globale NEGs. Sie können einem Backend-Dienst nur ein Internet-NEG-Backend hinzufügen.
    • Regionale NEGs. Sie können bis zu 50 Internet-NEGs zu demselben Backend-Dienst hinzufügen.

  • Anzahl der Endpunkte pro NEG

    • Globale NEGs. Sie können nur einen Endpunkt zu einer Internet-NEG hinzufügen.

      Da in jeder globalen Internet-NEG jeweils nur ein Endpunkt zulässig ist, wird das Load Balancing nicht ausgeführt. Der Load Balancer dient nur als Frontend und leitet Traffic an das angegebene externe Backend weiter. Das bedeutet, dass Sie keinen der Load Balancing-Modi verwenden können, wie z. B. Rate, Verbindung oder Auslastung.

    Regionale NEGs unterstützen keine Load-Balancing-Modi wie Rate, Verbindung oder Auslastung. Alle Endpunkte aller NEGs, die mit einem Backend-Dienst verknüpft sind, werden in einer einzigen Gruppe zusammengefasst. Der Load Balancing-Traffic zwischen diesem Pool der Endpunkte wird mithilfe von Envoy-Load Balancing-Algorithmen verarbeitet. Informationen zu den unterstützten Load Balancing-Richtlinienalgorithmen finden Sie unter localityLbPolicy in der API-Dokumentation für regionale Backend-Dienste.

  • Systemdiagnosen

    • Globale NEGs. Der Backend-Dienst darf nicht auf eine Systemdiagnose verweisen.

  • Das Load Balancing-Schema des Backend-Dienstes muss mit dem Schema übereinstimmen, das vom Load Balancer benötigt wird, den Sie bereitstellen. Eine vollständige Liste finden Sie unter Backend-Dienste.

  • Das Protokoll des Backend-Dienstes muss entweder HTTP, HTTPS oder HTTP2 sein.

    Wir empfehlen dringend, entweder HTTPS oder HTTP/2 als Protokoll zu verwenden, wenn Sie einen Backend-Dienst mit einer Internet-NEG konfigurieren. Damit wird die Kommunikation zwischen dem Load-Balancer und dem Backend verschlüsselt und authentifiziert, wenn das öffentliche Internet durchlaufen wird.

    Wenn Sie HTTPS oder HTTP/2 als Backend-Protokoll verwenden, müssen Sie außerdem einen INTERNET_FQDN_PORT-Endpunkt zum Erstellen Ihres externen Backends verwenden. Dies hat zwei Vorteile:

    • Dadurch wird sichergestellt, dass der Load-Balancer das SSL-Serverzertifikat validiert, das vom externen Backend bereitgestellt wird, und dass die folgenden Informationen wahr sind:

      • Ob das Zertifikat von bekannten Zertifizierungsstellen signiert wurde.
      • Ob das Zertifikat noch nicht abgelaufen ist
      • Ob die Zertifikatsignatur gültig ist
      • Ob der konfigurierte FQDN mit einem der alternativen Antragstellernamen (Subject Alternative Names, SANs) im Zertifikat übereinstimmt

      Wenn Sie das externe Backend mithilfe eines INTERNET_IP_PORT-Endpunkts erstellen, wird keine SSL-Serverzertifikat-Validierung durchgeführt.

    • Die SNI-Erweiterung (Server Name Indication) für SSL wird nur mit INTERNET_FQDN_PORT-Endpunkten unterstützt. Der konfigurierte FQDN sendet während des SSL-Handshakes zwischen dem Load-Balancer und dem externen Endpunkt ein SNI im Client-Hello. Das SNI wird nicht gesendet, wenn Sie einen INTERNET_IP_PORT-Endpunkt verwenden, da IP-Adressliterale im Feld HostName einer SNI-Nutzlast nicht zulässig sind.

Systemdiagnosen

Die Konfiguration der Systemdiagnose variiert je nach Art des Load Balancers:

  • Globaler externer Application Load Balancer und klassischer Application Load Balancer. Ein Backend-Dienst mit einer globalen Internet-NEG unterstützt keine Systemdiagnosen.

    Wenn Ihr externes Backend nicht mehr erreichbar ist oder der konfigurierte Hostname (FQDN) nicht aufgelöst werden kann, gibt der Load-Balancer die HTTP-Antwort 502 (Bad Gateway) an die Clients zurück.

  • Regionaler externer Application Load Balancer, regionaler interner Application Load Balancer, regionaler externer Proxy-Network Load Balancer und regionaler interner Proxy-Network Load Balancer. Systemdiagnosen sind optional. Systemdiagnoseprüfungen für diese Load Balancer stammen aus dem Nur-Proxy-Subnetz und werden dann (mithilfe von Cloud NAT) entweder in vorreservierte IP-Adressen oder automatisch zugewiesene NAT-IP-Adressen übersetzt. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT-Gateway verwenden.

    Verteilte Envoy-Systemdiagnosen werden mit der gleichen Google Cloud Console, gcloud CLI und API-Prozessen erstellt wie zentralisierte Systemdiagnosen. Es ist keine weitere Konfiguration erforderlich.

    Wichtige Hinweise:

    • gRPC-Systemdiagnosen werden nicht unterstützt.
    • Systemdiagnosen mit aktiviertem PROXY-Protokoll v1 werden nicht unterstützt.

    • Da die Envoy-Datenebene Systemdiagnosen verarbeitet, können Sie den Systemstatus der externen Endpunkte nicht mit der Google Cloud Console, der API oder der gcloud CLI prüfen. Bei Hybrid-NEGs mit Envoy-basierten Load Balancern zeigt die Google Cloud Console den Status der Systemdiagnose als N/A an. Dies ist zu erwarten.

    • Jeder Envoy-Proxy, der dem Nur-Proxy-Subnetz in der Region im VPC-Netzwerk zugewiesen ist, initiiert unabhängig Systemdiagnosen. Daher kann es aufgrund von Systemdiagnosen zu einem Anstieg des Netzwerktraffics kommen. Die Zunahme hängt von der Anzahl der Envoy-Proxys, die Ihrem VPC-Netzwerk in einer Region zugewiesen sind, der Menge des von diesen Proxys empfangenen Traffics und der Anzahl der Endpunkte ab, die jeder Envoy-Proxy für die Systemdiagnose benötigt. Im schlimmsten Fall steigt der Netzwerktraffic aufgrund von Systemdiagnosen quadratisch ((O(n^2))) an.

    • Systemdiagnose-Logs für verteilte Envoy-Systemdiagnosen enthalten keine detaillierten Systemzustände. Informationen dazu, was in Logs erfasst wird, finden Sie unter Systemdiagnose-Logging. Weitere Informationen zur Fehlerbehebung bei der Konnektivität von Envoy-Proxys zu Ihren NEG-Endpunkten finden Sie in den entsprechenden Load Balancer-Logs.

Externes Backend für den Empfang von Anfragen aktivieren

Konfigurieren Sie Ihr externes Backend so, dass Traffic von Google Cloud zugelassen wird.

Dieses Verfahren hängt vom Umfang der NEG ab: global oder regional.

Globale NEGs: Zulassungsliste für standardmäßige Egress-IP-Adressen von Google

Wenn Sie eine globale Internet-NEG verwenden, müssen Sie die IP-Adressbereiche, die Google zum Senden von Anfragen an externe Backends verwendet, auf die Zulassungsliste setzen. Wenn Sie die IP-Adressen suchen möchten, die auf eine Zulassungsliste gesetzt werden sollen, können Sie den DNS-TXT-Eintrag _cloud-eoips.googleusercontent.com mit einem Tool wie dig oder nslookup abfragen.

Ein Beispiel finden Sie unter Externem Backend erlauben, Traffic von Google Cloud zu empfangen.

Regionale NEGs: Cloud NAT-Gateway verwenden

Wenn Sie eine regionale Internet-NEG verwenden, müssen Sie zuerst ein Cloud NAT-Gateway einrichten, um eine Reihe von IP-Adressbereichen zuzuweisen, von denen der Google Cloud-Traffic stammen sollte.

Der Gateway-Endpunkt muss vom Typ ENDPOINT_TYPE_MANAGED_PROXY_LB sein.

Das Cloud NAT-Gateway kann so konfiguriert werden, dass entweder externe IP-Adressen nach Bedarf automatisch zugewiesen werden oder ein manuell vorab reservierter Satz externer IP-Adressen verwendet wird.

  • Automatisch zugewiesene IP-Adressen

    Verwenden Sie automatisch zugeordnete IP-Adressen, wenn Sie in Ihrer externen Backend-Umgebung keine bestimmten Google Cloud-IP-Adressen, die Traffic an das externe Backend senden können, auf eine Zulassungsliste setzen müssen.

  • Manuell zugeordnete IP-Adressen

    Verwenden Sie manuell zugeordnete IP-Adressen nur, wenn Ihre externe Backend-Umgebung erfordert, dass Sie einer Zulassungsliste bestimmte Google Cloud-IP-Adressen hinzufügen. Da jeder Envoy, der Ihrem Proxy-Subnetz zugewiesen ist, eine vollständige IP-Adresse nutzt, muss der Pool reservierter IP-Adressen groß genug sein, um alle Envoys verarbeiten zu können.

    Wenn umfangreiche Verbindungsprobleme auftreten, prüfen Sie, ob Sie die Cloud NAT-Limits erreicht haben. Standardmäßig sind pro Gateway auf 50 manuell zugewiesene NAT-IP-Adressen beschränkt.

Diese Cloud NAT-Konfiguration gilt für das gesamte Nur-Proxy-Subnetz. Der Internet-Traffic, der allen regionalen Envoy-basierten Load Balancern in der Region zugeordnet ist, hat dasselbe NAT-Gateway.

Für die Cloud NAT-Nutzung fallen sowohl für den Nutzertraffic als auch für die Systemdiagnose Gebühren an. Weitere Informationen zu den Preisen für regionale Internet-NEGs finden Sie unter Preise für regionale Internet-NEGs.

Für NAT-Gateways in Nur-Proxy-Subnetzen gelten bestimmte Einschränkungen:

  • Es wird nur 1:1-NAT-Übersetzung durchgeführt. Die Freigabe von IP-Adressen wird nicht unterstützt.
  • Logging und Monitoring werden nicht unterstützt. Das heißt, die Flags --enable-logging und --log-filter werden nicht unterstützt.
  • Portbezogene Features wie statische und dynamische Portzuweisung, das Festlegen von maximalen und minimalen Ports pro VM und die endpunktunabhängige Zuordnung werden nicht unterstützt. Jeder Proxy erhält alle 65.536 Ports.

Anfragen an das externe Backend authentifizieren

Dieser Abschnitt gilt nur für Application Load Balancer.

Zum Authentifizieren von Anfragen, die an Ihr externes Backend gesendet werden, haben Sie folgende Möglichkeiten:

  • Bestimmen Sie einen benutzerdefinierten Header, der angibt, dass die Anfrage von einem Google Cloud Application Load Balancer mit einem benutzerdefinierten Anfrageheader stammt. Beispielsweise können Sie 16 oder mehr kryptografisch zufällige Byte als gemeinsam genutzten Schlüssel verwenden.

    Implementieren von benutzerdefinierten Header-Transformationen je nach Art des verwendeten Load Balancers:

    • Globaler externer Application Load Balancer und klassischer Application Load Balancer. Benutzerdefinierte Header-Transformationen können entweder für den Backend-Dienst oder für die URL-Zuordnung konfiguriert werden.

      Beispiel: Sie können das externe Backend so konfigurieren, dass für den Host-Header der HTTP-Anfrage ein bestimmter Wert erwartet wird, und Sie können den Load Balancer so konfigurieren, dass der Host-Header auf diesen erwarteten Wert gesetzt wird. Wenn Sie keinen benutzerdefinierten Anfrageheader konfigurieren, behält der Load Balancer die Header bei, die der Client für die Verbindung mit dem Load Balancer verwendet hat, und nimmt denselben Header in die Antwort auf. Beachten Sie jedoch, dass das Ändern des Headers Host in der URL-Zuordnung nicht unterstützt wird.

      Beim Konfigurieren des Headers Host gelten zusätzliche Einschränkungen. Weitere Informationen finden Sie unter Benutzerdefinierte Header in Backend-Diensten erstellen. Ein konkretes Beispiel finden Sie unter Globalen externen Application Load Balancer mit einem externen Backend einrichten.

    • Regionaler externer Application Load Balancer und regionaler interner Application Load Balancer. Benutzerdefinierte Header-Transformationen können nur für die URL-Zuordnung konfiguriert werden.

      Für diese Envoy-basierten Load Balancer sind Host und authority spezielle Keywords, die von Google Cloud reserviert werden. Sie können diese Header nicht für diese Load Balancer ändern. Stattdessen empfehlen wir, andere benutzerdefinierte Header (z. B. MyHost) zu erstellen, damit Sie die reservierten Headernamen nicht beeinträchtigen.

  • Aktivieren Sie IAP und prüfen Sie, ob das signierte JWT im Anfrageheader von Google signiert ist und die aud (Zielgruppen-) Anforderung die Nummer des Projekts enthält, in dem der Load Balancer definiert ist.

    Wichtige Hinweise:

    • IAP ist nicht mit Cloud CDN kompatibel.
    • IAP wird nicht mit regionalen externen Application Load Balancern und Proxy-Network Load Balancern (intern und extern) unterstützt.
  • Aktivieren Sie die private Ursprungsauthentifizierung, die einem externen Application Load Balancer langfristig Zugriff auf einen privaten Amazon S3-Bucket (Amazon Simple Storage Service) oder einen anderen kompatiblen Objektspeicher gewährt. Cloud CDN (und damit die Authentifizierung über einen privaten Ursprung) wird nicht mit regionalen externen Application Load Balancern und regionalen internen Application Load Balancern unterstützt.

Logs

An ein externes Backend weitergeleitete Anfragen werden in Cloud Logging auf dieselbe Weise in Logs erfasst wie Anfragen an andere Backends.

Hier finden Sie weitere Informationen:

Wenn Sie Cloud CDN für einen externen Application Load Balancer mit einem externen Backend aktivieren, werden Cache-Treffer ebenfalls in Logs erfasst.

Headerverarbeitung mit externen Back-Ends

Verschiedene Load Balancer verarbeiten die Headerverarbeitung möglicherweise unterschiedlich, wenn sie Anfragen an ein externes Backend weiterleiten. In den folgenden Informationen erfahren Sie, wie HTTP-Header möglicherweise von Ihrem Load Balancer-Typ verarbeitet werden.

Globale externe Application Load Balancer und klassische Application Load Balancer

Wenn ein globaler externer Application Load Balancer oder ein klassischer Application Load Balancer Anfragen an ein externes Backend weiterleitet, werden die HTTP-Header so angepasst:

  • Einige Header werden zusammengeführt. Wenn mehrere Instanzen mit demselben Headerschlüssel vorhanden sind, z. B. Via, kombiniert der Load-Balancer deren Werte in einer durch Kommas getrennten Liste zu einem einzelnen Headerschlüssel. Es werden nur Header zusammengeführt, deren Werte als durch Kommas getrennte Liste dargestellt werden können. Andere Header wie Set-Cookie werden nie zusammengeführt.

  • Wenn der Backend-Dienst das Protokoll HTTP oder HTTPS verwendet, müssen die Header das folgende Format haben:

    • Der erste Buchstabe im Schlüssel des Headers und jeder Buchstabe nach einem Bindestrich (-) werden groß geschrieben, um die Kompatibilität mit HTTP/1.1-Clients zu wahren. Beispiel: user-agent wird in User-Agent geändert und content-encoding in Content-Encoding.

    • Bestimmte Header wie Accept-CH (Clienthinweise) werden entsprechend der standardmäßigen gemischten Buchstabenkombination konvertiert.

  • Einige Header werden hinzugefügt oder Werte werden an sie angehängt. Die externen Application Load Balancer fügen immer bestimmte Header wie Via und X-Forwarded-For hinzu oder ändern sie.

Regionale externe Application Load Balancer und regionale interne Application Load Balancer

Es gibt keine spezielle Headerverarbeitung für Envoy-basierte Load Balancer, die Internet-NEGs verwenden. Informationen dazu, wie Envoy normalerweise Header verarbeitet, finden Sie unter HTTP-Header-Bearbeitung.

Beschränkungen

  • Im Abschnitt Backend-Dienst finden Sie Einschränkungen für die Konfiguration von Internet-NEGs als Backends.
  • Wenn Sie einen Load Balancer ändern, um das Backend von einer Internet-NEG in einen anderen Backend-Typ oder das Backend von einem anderen Backend-Typ in eine Internet-NEG zu ändern, kommt es zu einer vorübergehenden Ausfallzeit Ihrer Anwendung von etwa 30 bis 90 Sekunden. Während dieser Ausfallzeit zeigen Clients, die Anfragen an globale externe Application Load Balancer senden, beispielsweise 502-Fehler mit dem Fehlercode failed_to_connect_to_backend. Das ist ganz normal.
  • Die folgenden Features für die erweiterte Trafficverwaltung werden für globale Internet-NEG-Back-Ends nicht unterstützt:
    • Spiegelung anfordern
    • Richtlinien für Wiederholungsversuche
    • Trafficrichtlinien, einschließlich Load-Balancing-Richtlinie für den Ort, Sitzungsaffinität und Ausreißererkennung
  • Im Abschnitt Cloud NAT-Gateway finden Sie Einschränkungen im Zusammenhang mit NAT-Gateways, die in Nur-Proxy-Subnetzen konfiguriert sind.

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie in der Kontingenttabelle für NEG-Backends und in der Kontingenttabelle der Endpunkte pro NEG.

Preise

Ausgehender Traffic an externe Internet-NEG-Endpunkte wird zu den Preisen für ausgehenden Internettraffic der Premium-Stufe berechnet. Die Quelle basiert auf dem Standort des Clients und das Ziel richtet sich nach dem Standort Ihres öffentlichen Endpunkts.

Wenn Sie ein Cloud NAT-Gateway konfiguriert haben, um das Nur-Proxy-Subnetz Ihres regionalen Envoy-basierten Load Balancers zuzuordnen, fallen Cloud NAT-Gebühren an. Für Cloud NAT-Gateways, die Load Balancern zugewiesen sind, fallen stündliche Gebühren an, die einem Netzwerk mit mehr als 32 VM-Instanzen entsprechen. Weitere Informationen finden Sie unter Cloud NAT-Preise.

Weitere Informationen finden Sie unter Cloud Load Balancing – Preise.

Nächste Schritte