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.
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. Wenn Sie ein externes Backend mit Cloud Service Mesh verwenden möchten, lesen Sie den Hilfeartikel 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.
Regional, extern
Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen externen Application Load Balancers mit einem externen Backend erforderlich sind.
Regional intern
Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen internen Application Load Balancers mit einem externen Backend erforderlich sind.
Diese Abbildung zeigt die Google Cloud-Ressourcen, die zum Einrichten eines regionalen internen Proxy-Network Load Balancer mit einem externen Backend erforderlich sind.
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:
- Übersicht über externen Application Load Balancer
- Übersicht über internen Application Load Balancer
- Übersicht über externen Proxy-Network-Load-Balancer
- Interner Proxy-Network Load Balancer – Übersicht
Internet-NEG
Eine Internet-NEG ist eine globale Ressource, mit der ein externes Backend für den Load Balancer definiert wird. Es gibt zwei Arten von Internet-NEGs: globale Internet-NEGs und regionale Internet-NEGs. Sie unterscheiden sich hinsichtlich ihres Geltungsbereichs (global oder regional) und ihres Verhaltens. Das externe Backend, auf das von einer globalen Internet-NEG verwiesen wird, muss ausschließlich über das Internet erreichbar sein. Es darf nicht ü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
. Wenn das Format INTERNET_IP_PORT
ausgewählt wird, kann nur eine öffentlich routbare IP-Adresse verwendet werden. Wenn das Format INTERNET_FQDN_PORT
ausgewählt wird, kann der FQDN je nach Umfang des Endpunkts (regional oder global) entweder auf eine öffentlich routbare IP-Adresse oder auf eine private IP-Adresse aufgelöst werden.
Globale Internet-NEGs basieren auf Google Front End (GFE)-Technologien. 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 | Definition des Endpunkts | Umfang | Systemdiagnosen |
---|---|---|---|---|
|
|
Ein öffentlich auflösbarer, voll qualifizierter Domainname und ein optionaler Port. Zum Beispiel
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 |
|
Eine öffentlich weiterleitbare IP-Adresse und ein optionaler Port. Zum Beispiel:
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 | Definition des Endpunkts | Umfang | Systemdiagnosen |
---|---|---|---|---|
|
|
Entweder ein öffentlich oder privat auflösbarer, voll qualifizierter Domainname und ein optionaler Port. Zum Beispiel
Die Domainnamensauflösung erfolgt gemäß der Reihenfolge der Cloud DNS-Namensauflösung. Pro NEG sind maximal 256 Endpunkte zulässig. |
Regional | Verteilte Envoy-Systemdiagnosen |
|
Nur eine öffentlich weiterleitbare IP-Adresse und ein optionaler Port. Beispiel:
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 oder DNS-Peering aufgelöst werden können, wenn er auf eine private DNS-Zone in einem anderen VPC-Netzwerk verweist.
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. Konkrete Konfigurationsschritte finden Sie in der Cloud DNS-Dokumentation. Die Reihenfolge der Cloud DNS-Auflösung wird unter Reihenfolge der Namensauflösung beschrieben.
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 Domainnamenauflösung sowohl mit Cloud DNS als auch mit dem öffentlichen DNS von Google.
- Bei der öffentlichen DNS-Auflösung leitet Cloud DNS den Traffic an die öffentlichen DNS-Server von Google weiter.
- Für Cloud DNS muss der Domainname einer der folgenden Typen sein:
- In Cloud DNS gehostet
- Sie müssen mithilfe der DNS-Weiterleitung von Cloud DNS zu einem lokalen DNS-Server aufgelöst werden können.
- Sie können mit DNS-Peering aufgelöst werden, wenn Sie auf eine private DNS-Zone in einem anderen VPC-Netzwerk verweisen.
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 basierend auf der DNS-TTL regelmäßig aktualisiert. Sie können Wiederholrichtlinien konfigurieren, um Envoy zu zwingen, bei einem Fehler eine Verbindung zu einer anderen IP-Adresse herzustellen.
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 Backend-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. Sie können einem Backend-Dienst bis zu 256 Endpunkte pro NEG hinzufügen.
Regionale NEGs unterstützen keine Load-Balancing-Modi wie Rate, Verbindung oder Auslastung. Alle Endpunkte aller NEGs, die mit einem Back-End-Dienst verbunden 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.
- Regionale NEGs. Der Load Balancer verwendet verteilte Envoy-Systemdiagnosen.
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
oderHTTP2
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 einenINTERNET_IP_PORT
-Endpunkt verwenden, da IP-Adressliterale im FeldHostName
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 Back-End-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. Gesundheitschecks 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, startet die Systemdiagnose unabhängig voneinander. Daher kann es vorkommen, dass der Netzwerktraffic aufgrund von Systemdiagnosen zunimmt. 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.
Dieser Vorgang 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 eine Zulassungsliste setzen. Wenn Sie die IP-Adressen suchen möchten, die einer Zulassungsliste hinzugefügt 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 sollte 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 bestimmte Google Cloud-IP-Adressen auf eine Zulassungsliste setzen. 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 Sie auf großem Maßstab Verbindungsprobleme haben, 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.
Die Cloud NAT-Nutzung wird sowohl für Nutzer- als auch für Systemdiagnose-Traffic in Rechnung gestellt. Weitere Informationen zur Preisgestaltung für regionale Internet-NEGs finden Sie unter Preisgestaltung für regionale Internet-NEGs.
Für NAT-Gateways in Nur-Proxy-Subnetzen gelten bestimmte Einschränkungen:
- Es wird nur eine 1:1-NAT-Übersetzung durchgeführt. Die Freigabe von IP-Adressen wird nicht unterstützt.
- Logging und Monitoring werden nicht unterstützt. Die Flags
--enable-logging
und--log-filter
werden also nicht unterstützt. - Portbezogene Funktionen wie die statische und dynamische Portzuweisung, das Festlegen der maximalen und minimalen Anzahl von 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.
So authentifizieren Sie Anfragen, die an Ihr externes Backend gesendet werden:
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 derHost
-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. Die Änderung desHost
-Headers wird in der URL-Zuordnung jedoch nicht unterstützt.Für die Konfiguration des
Host
-Headers 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
undauthority
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:
- Logging von regionalen externen Application Load Balancern
- Logging von regionalen internen Application Load Balancern
- Logging von Proxy-Network Load Balancern
Headerverarbeitung mit externen Back-Ends
Unterschiedliche Load Balancer können die Headerverarbeitung unterschiedlich handhaben, 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 wieSet-Cookie
werden nie zusammengeführt.Wenn der Backend-Dienst das Protokoll
HTTP
oderHTTPS
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 inUser-Agent
geändert undcontent-encoding
inContent-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
undX-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 Header normalerweise verarbeitet, finden Sie unter HTTP-Header-Manipulation.
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 Fehlercodefailed_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 für NAT-Gateways, die in Nur-Proxy-Subnetzen konfiguriert sind.
Kontingente und Limits
Informationen zu Kontingenten und Limits finden Sie in den Tabellen Kontingenttabelle für NEG-Back-Ends und Kontingenttabelle für 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
- Globalen externen Application Load Balancer mit einer Internet-NEG einrichten
- Klassischen Application Load Balancer mit einer Internet-NEG einrichten
- Cloud CDN für einen externen Application Load Balancer mit einem externen Backend einrichten
- Cloud Service Mesh mit Internetnetzwerk-Endpunktgruppen – Übersicht
- Regionalen externen Application Load Balancer mit einer Internet-NEG einrichten
- Regionalen externen Proxy-Network Load Balancer mit einer Internet-NEG einrichten