Interner Application Load Balancer – Übersicht

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie interne Application Load Balancer konfigurieren möchten.

Ein interner Google Cloud Application Load Balancer ist ein proxy-basierter, Layer-7-Load Balancer, mit dem Sie Ihre Dienste hinter einer einzigen IP-Adresse ausführen und skalieren können. Der interne Application Load Balancer verteilt HTTP- und HTTPS-Traffic an Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine, Google Kubernetes Engine (GKE) und Cloud Run gehostet werden. Weitere Informationen finden Sie unter Anwendungsfälle.

Betriebsarten

Sie können einen externen Application Load Balancer in den folgenden Modi konfigurieren:

  • Regionenübergreifender interner Application Load Balancer. Dies ist ein multiregionaler Load Balancer, der als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert ist. Mit dem regionenübergreifenden Modus können Sie Traffic auf global verteilte Backend-Dienste verteilen, einschließlich der Trafficverwaltung, die dafür sorgt, dass der Traffic an das nächstgelegene Backend weitergeleitet wird. Dieser Load Balancer ermöglicht auch Hochverfügbarkeit. Durch die Platzierung von Backends in mehreren Regionen lassen sich Fehler in einer einzelnen Region vermeiden. Wenn die Back-Ends einer Region ausfallen, kann der Traffic auf eine andere Region umgeleitet werden.

  • Regionaler interner Application Load Balancer. Dies ist ein regionaler Load Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Der regionale Modus stellt sicher, dass alle Clients und Back-Ends aus einer bestimmten Region stammen, was hilfreich ist, wenn Sie regionale Compliance benötigen. Dieser Load Balancer wird mit umfangreichen Trafficsteuerungsfunktionen aktiviert, die auf HTTP(S)-Parametern basieren. Nachdem der Load Balancer konfiguriert wurde, werden automatisch Envoy-Proxys zugewiesen, um Ihre Trafficanforderungen zu erfüllen.

    In der folgenden Tabelle werden die wichtigen Unterschiede zwischen regionalen und regionenübergreifenden Modi beschrieben:

    Funktion Regionsübergreifender interner Application Load Balancer Regionaler interner Application Load Balancer
    Virtuelle IP-Adresse (VIP) des Load Balancers. Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen.

    VIP-Adressen aus mehreren Regionen können denselben globalen Backend-Dienst verwenden. Sie können das DNS-basierte globale Load Balancing mithilfe von DNS-Routingrichtlinien konfigurieren, um Clientanfragen an die nächstgelegene VIP-Adresse weiterzuleiten.

    		 Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen.
    Clientzugriff Zugriff immer global. Clients aus jeder Google Cloud-Region in einer VPC können Traffic an den Load Balancer senden. Zugriff ist standardmäßig nicht global möglich.
    (Optional) Sie können den globalen Zugriff aktivieren.
    Back-Ends mit Load Balancing Globale Back-Ends.
    Der Load Balancer kann Traffic an Back-Ends in jeder Region senden.    		 Regionale Back-Ends.
    Der Load Balancer kann Traffic nur an Back-Ends senden, die sich in derselben Region wie der Proxy des Load Balancers befinden.
    Hochverfügbarkeit und Failover Automatisches Failover auf fehlerfreie Backends in derselben oder in unterschiedlichen Regionen. Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.

Modus bestimmen

Cloud Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Auf dem Tab Load Balancer werden der Typ, das Protokoll und die Region des Load Balancers angezeigt. Wenn die Region leer ist, befindet sich der Load Balancer im regionenübergreifenden Modus. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

    Load-Balancer-Modus Load Balancer-Typ Zugriffstyp Region
    Regionaler interner Application Load Balancer Anwendung Intern Gibt eine Region an
    Regionsübergreifender interner Application Load Balancer Anwendung Intern

gcloud

  1. Führen Sie den folgenden Befehl aus, um den Modus eines Load-Balancers zu bestimmen:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    Prüfen Sie in der Befehlsausgabe das Load-Balancing-Schema, die Region und die Netzwerkstufe. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

    Load-Balancer-Modus Load-Balancing-Schema Weiterleitungsregel
    Regionsübergreifender interner Application Load Balancer INTERNAL_MANAGED Global
    Regionaler interner Application Load Balancer INTERNAL_MANAGED Regional

Architektur und Ressourcen

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für interne Application Load Balancer in den einzelnen Modi erforderlich sind:

Regionsübergreifend

Dieses Diagramm zeigt die Komponenten der regionsübergreifenden internen Bereitstellung des Application Load Balancers in der Premium-Stufe innerhalb desselben VPC-Netzwerks. Jede globale Weiterleitungsregel verwendet eine regionale IP-Adresse, mit der die Clients eine Verbindung herstellen.

Komponenten eines regionenübergreifenden internen Application Load Balancers.
Komponenten des regionsübergreifenden internen Application Load Balancers (zum Vergrößern klicken)

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen internen Application Load Balancers in der Premium-Stufe.

Komponenten eines regionalen internen Application Load Balancers.
Nummerierte Komponenten des regionalen internen Application Load Balancers (zum Vergrößern klicken).

Jeder interne Application Load Balancer verwendet die folgenden Google Cloud-Konfigurationsressourcen.

Nur-Proxy-Subnetz

Im obigen Diagramm stellt das Nur-Proxy-Subnetz eine Reihe von IP-Adressen bereit, die Google zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie interne Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen.

In der folgenden Tabelle werden die Unterschiede zwischen Nur-Proxy-Subnetzen im regionalen und regionenübergreifenden Modus beschrieben:

Load-Balancer-Modus Wert des Flags --purpose des Nur-Proxy-Subnetzes
Regionsübergreifender interner Application Load Balancer

GLOBAL_MANAGED_PROXY

Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden

Der regionenübergreifende Envoy-basierte Load Balancer muss in jeder Region, in der der Load Balancer konfiguriert ist, ein Nur-Proxy-Subnetz haben. Regionenübergreifende Load Balancer-Proxys in derselben Region und demselben Netzwerk verwenden dasselbe Nur-Proxy-Subnetz.
Regionaler interner Application Load Balancer

REGIONAL_MANAGED_PROXY

Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden

Alle regionalen Envoy-basierten Load Balancer in einer Region und einem VPC-Netzwerk verwenden dasselbe Nur-Proxy-Subnetz

Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Backend-VMs bzw. Endpunkte aller internen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine intern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.

Weiterleitungsregel und IP-Adresse

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy und einem Backend-Dienst besteht.

Jede Weiterleitungsregel verweist auf eine einzelne regionale IP-Adresse, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Sie können entweder eine statische IP-Adresse reservieren, die Sie verwenden können, oder Cloud Load Balancing eine Adresse für Sie zuweisen lassen. Wir empfehlen, eine statische IP-Adresse zu reservieren. Andernfalls müssen Sie den DNS-Eintrag jedes Mal, wenn Sie eine Weiterleitungsregel löschen und eine neue erstellen, mit der neu zugewiesenen sitzungsspezifischen IP-Adresse aktualisieren.

Clients verwenden die IP-Adresse und den Port, um eine Verbindung zu den Envoy-Proxys des Load Balancers herzustellen. Die IP-Adresse der Weiterleitungsregel ist die IP-Adresse des Load Balancers (manchmal auch virtuelle IP-Adresse oder VIP genannt). Clients, die eine Verbindung zu einem Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. Eine vollständige Liste der unterstützten Protokolle finden Sie unter Load Balancer-Features.

Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus einem Subnetz im selben Netzwerk und in derselben Region wie die Backends stammen.

Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Damit mehrere Ports unterstützt werden können, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe interne IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP(S)-Proxy verweisen, solange die gesamte Kombination von IP-Adresse, Port und Protokoll für jede Weiterleitungsregel eindeutig ist. Auf diese Weise können Sie einen einzelnen Load Balancer mit einer freigegebenen URL-Zuordnung als Proxy für mehrere Anwendungen verwenden.

Die folgende Tabelle zeigt die Unterschiede zwischen Weiterleitungsregeln in den regionalen und regionenübergreifenden Modi:

Load-Balancer-Modus Weiterleitungsregel, IP-Adresse und Nur-Proxy-Subnetz --purpose Routing vom Client zum Frontend des Load Balancers
Regionsübergreifender interner Application Load Balancer

Globale Weiterleitungsregel

Regionale IP-Adressen

Load Balancing-Schema:

INTERNAL_MANAGED

Nur-Proxy-Subnetz: --purpose

GLOBAL_MANAGED_PROXY

IP-Adresse --purpose:

SHARED_LOADBALANCER_VIP

Der globale Zugriff ist standardmäßig aktiviert, damit Clients aus jeder Region in einer VPC auf den Load Balancer zugreifen können. Back-Ends können sich in mehreren Regionen befinden.
Regionaler interner Application Load Balancer

Regionale Weiterleitungsregel

Regionale IP-Adresse

Load Balancing-Schema:

INTERNAL_MANAGED

Nur-Proxy-Subnetz: --purpose

REGIONAL_MANAGED_PROXY

IP-Adresse --purpose:

SHARED_LOADBALANCER_VIP

Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können. Backends müssen sich auch in derselben Region wie der Load Balancer befinden.

Zielproxy

Ein HTTP(S)-Zielproxy beendet HTTP(S)-Verbindungen von Clients. Der HTTP(S)-Proxy prüft die URL-Zuordnung, um zu ermitteln, wie Traffic an Back-Ends weitergeleitet wird. Ein Ziel-HTTPS-Proxy verwendet ein SSL-Zertifikat, um sich bei Clients zu authentifizieren.

Der Load-Balancer behält den Host-Header der ursprünglichen Clientanfrage bei. Der Load-Balancer hängt außerdem zwei IP-Adressen an den Header X-Forwarded-For an:

  • Die IP-Adresse des Clients, der eine Verbindung zum Load-Balancer herstellt
  • Die IP-Adresse der Weiterleitungsregel des Load-Balancers

Wenn in der eingehenden Anfrage kein X-Forwarded-For-Header vorhanden ist, stellen diese beiden IP-Adressen den gesamten Header-Wert dar. Wenn die Anfrage einen X-Forwarded-For-Header hat, werden andere Informationen wie die von Proxys auf dem Weg zum Load-Balancer erfassten IP-Adressen vor den beiden IP-Adressen gespeichert. Der Load-Balancer überprüft keine IP-Adressen, die vor den letzten beiden IP-Adressen in diesem Header liegen.

Wenn Sie einen Proxy als Back-End-Server ausführen, fügt dieser Proxy in der Regel weitere Informationen an den Header X-Forwarded-For an. Dies kann in Ihrer Software erforderlich sein. Die weitergeleiteten Anfragen vom Load-Balancer stammen von einer IP-Adresse im Nur-Proxy-Subnetz. Ihr Proxy auf der Backend-Instanz erfasst möglicherweise diese Adresse sowie die eigene IP-Adresse der Backend-Instanz.

Je nach der Art des Traffics, den Ihre Anwendung verarbeiten muss, können Sie einen Load Balancer mit einem Ziel-HTTP-Proxy oder einem Ziel-HTTPS-Proxy konfigurieren.

Die folgende Tabelle zeigt die Zielproxy APIs, die für die internen Application Load Balancer in den einzelnen Modi erforderlich sind:

Zielproxy Regionsübergreifender interner Application Load Balancer Regionaler interner Application Load Balancer
HTTP Global targetHttpProxies regionTargetHttpProxies
HTTPS Global targetHttpsProxies regionTargetHttpsProxies

SSL-Zertifikate

Interne Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

In der folgenden Tabelle ist der Typ der SSL-Zertifikate angegeben, die von internen Application Load Balancern in den einzelnen Modi benötigt werden:

Load-Balancer-Modus SSL-Zertifikatstyp
Regionaler interner Application Load Balancer

Regionale Compute Engine-SSL-Zertifikate

Von Zertifikatmanager selbst verwaltete regionale Zertifikate und von Google verwaltete Zertifikate.

Die folgenden Typen der von Google verwalteten Zertifikate werden von Zertifikatmanager unterstützt:

Von Google verwaltete Zertifikate mit Load Balancer-Autorisierung werden nicht unterstützt.
Regionsübergreifender interner Application Load Balancer

Von Certificate Manager selbst verwaltete Zertifikate und von Google verwaltete Zertifikate.

Die folgenden Typen der von Google verwalteten Zertifikate werden von Certificate Manager unterstützt:

Von Google verwaltete Zertifikate mit Load Balancer-Autorisierung werden nicht unterstützt.

Compute Engine-SSL-Zertifikate werden nicht unterstützt.

URL-Zuordnungen

Der HTTP(S)-Zielproxy verwendet URL-Zuordnungen, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Anhand dieser Entscheidung leitet der Proxy Clientanfragen an bestimmte Backend-Dienste weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, unter anderem das Überschreiben von Headern, das Senden von Weiterleitungen an Clients und das Konfigurieren von Zeitlimitrichtlinien.

In der folgenden Tabelle ist der Typ der URL-Zuordnung angegeben, der von internen Application Load Balancern in den einzelnen Modi benötigt wird:

Load-Balancer-Modus Typ der URL-Zuordnung
Regionsübergreifender interner Application Load Balancer Globale URL-Zuordnungen
Regionaler interner Application Load Balancer Regions-URL-Zuordnungen

Backend-Dienst

Ein Backend-Dienst verteilt Anfragen an fehlerfreie Backends: Instanzgruppen mit Compute Engine-VMs, Cloud Run oder NEGs mit GKE-Containern.

Backend-Dienste unterstützen die HTTP-, HTTPS- oder HTTP/2-Protokolle. HTTP/2 wird nur über TLS unterstützt. Clients und Back-Ends müssen nicht dasselbe Anfrageprotokoll verwenden. Clients können beispielsweise Anfragen mit HTTP/2 an den Load-Balancer senden und der Load-Balancer kann diese Anfragen mit HTTP/1.1 an Back-Ends weiterleiten.

In der folgenden Tabelle ist der Backend-Diensttyp angegeben, der von internen Application Load Balancern in den einzelnen Modi benötigt wird:

Load-Balancer-Modus Typ des Backend-Dienstes
Regionsübergreifender interner Application Load Balancer Globale Backend-Dienste
Regionaler interner Application Load Balancer Regionale Backend-Dienste

In der folgenden Tabelle sind die Backend-Features aufgeführt, die von internen Application Load Balancern in den einzelnen Modi unterstützt werden.


Load-Balancer-Modus 		Unterstützte Backends in einem Backend-Dienst Unterstützt Back-End-Buckets Unterstützt Google Cloud Armor Unterstützt Cloud CDN. Unterstützt IAP Unterstützt Diensterweiterungen
Instanzgruppen Zonale NEGs Internet-NEGs Serverlose NEGs Hybrid-NEGs Private Service Connect-NEGs
Regionsübergreifender interner Application Load Balancer 2
Cloud Run
Regionaler interner Application Load Balancer 1
Cloud Run

1 Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden oder Ingress verwenden

2 Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden

Weitere Informationen finden Sie unter Übersicht über Backend-Dienste.

Back-Ends und VPC-Netzwerke

Alle Backends müssen sich in demselben VPC-Netzwerk befinden. Das Platzieren von Back-Ends in verschiedenen VPC-Netzwerken, auch wenn diese über VPC-Netzwerk-Peering verbunden sind, wird nicht unterstützt. Weitere Informationen dazu, wie Clientsysteme in Peering-VPC-Netzwerken auf Load-Balancer zugreifen können, finden Sie unter Interner Application Load Balancer und verbundene Netzwerke.

Backend-Teilmengeneinstellung

Die Backend-Teilmengeneinstellung ist eine optionale Funktion, die vom regionalen internen Application Load Balancer unterstützt wird und die Leistung und Skalierbarkeit verbessert, indem jeder Proxy-Instanz eine Teilmenge von Backends zugewiesen wird.

Standardmäßig ist die Backend-Teileinstellung deaktiviert. Informationen zum Aktivieren dieser Funktion finden Sie unter Backend-Teilmengeneinstellung für internen Application Load Balancer.

Systemdiagnosen

Jeder Backend-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Backends überwacht, eine Verbindung vom Load-Balancer zu erhalten. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können. Systemdiagnosen prüfen nicht, ob die Anwendung selbst funktioniert.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Backend-Instanzen erreichen können. In der Regel gehen Systemdiagnoseprüfungen vom zentralen Systemdiagnosemechanismus von Google aus. Bei Hybrid-NEGs stammen Systemdiagnosen jedoch stattdessen vom Nur-Proxy-Subnetz. Weitere Informationen finden Sie unter Verteilte Systemdiagnosen für Envoy in der Übersicht der Hybrid-NEGs.

Systemdiagnoseprotokoll

Obwohl es nicht erforderlich und nicht immer möglich ist, empfiehlt es sich, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Backend-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Im Gegensatz dazu unterstützen interne Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von internen Application Load Balancern in den einzelnen Modi unterstützt werden:

Load-Balancer-Modus Systemdiagnosetyp
Regionsübergreifender interner Application Load Balancer Global
Regionaler interner Application Load Balancer Regional

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für einen internen Application Load Balancer sind die folgenden Firewallregeln erforderlich:

Für die folgenden Bereiche gelten bestimmte Ausnahmen von den Firewallregeln:

  • Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.
  • Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuelle oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT für ausgehenden Traffic verwenden.

Clientzugriff

Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist.

Für regionenübergreifende interne Application Load Balancer ist der globale Zugriff standardmäßig aktiviert. Clients aus jeder Region in einer VPC können auf Ihren Load Balancer zugreifen.

Bei regionalen internen Application Load Balancern müssen sich Clients standardmäßig in derselben Region wie der Load Balancer befinden. Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können.

In der folgenden Tabelle wird der Clientzugriff für regionale interne Application Load Balancer zusammengefasst:

Globaler Zugriff deaktiviert Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

Architekturen freigegebener VPCs

Interne Application Load Balancer unterstützen Netzwerke, die eine freigegebene VPC verwenden. Eine freigegebene VPC ermöglicht Organisationen, Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, einen internen Application Load Balancer in einem freigegebenen VPC-Netzwerk zu konfigurieren. Unabhängig vom Bereitstellungstyp müssen sich alle Komponenten des Load-Balancers in derselben Organisation befinden.

Subnetze und IP-Adresse Frontend-Komponenten Backend-Komponenten

Erstellen Sie das erforderliche Netzwerk und die Subnetze (einschließlich des Nur-Proxy-Subnetzes) im freigegebenen VPC-Hostprojekt.

Die interne IP-Adresse des Load-Balancers kann entweder im Hostprojekt oder in einem Dienstprojekt definiert werden. Sie muss jedoch ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verwenden. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

 Die regionale interne IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein. Sie haben folgende Möglichkeiten:
  • Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) im selben Dienstprojekt wie die Frontend-Komponenten.
  • Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) in so vielen Dienstprojekten wie nötig. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet.

Jeder Backend-Dienst muss im selben Projekt wie die Backends definiert werden, auf die er verweist. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebenen VPC-Hostprojekt erstellen, aber die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung werden bei diesem Modell nicht getrennt.

Alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt

Das folgende Architekturdiagramm zeigt eine standardmäßige Bereitstellung einer freigegebenen VPC, bei der sich alle Load-Balancer-Komponenten und Backends in einem Dienstprojekt befinden. Dieser Bereitstellungstyp wird von allen Application Load Balancern unterstützt.

Der Load-Balancer verwendet IP-Adressen und Subnetze aus dem Hostprojekt. Clients können auf einen internen Application Load Balancer zugreifen, wenn sie sich im selben freigegebenen VPC-Netzwerk und in derselben Region wie der Load Balancer befinden. Clients können sich im Hostprojekt, in einem angehängten Dienstprojekt oder in verbundenen Netzwerken befinden.

Interner Application Load Balancer in einem freigegebenen VPC-Netzwerk
Interner Application Load Balancer in freigegebenem VPC-Netzwerk

Serverlose Backends in einer freigegebenen VPC-Umgebung**

Bei einem internen Application Load Balancer, der ein serverloses NEG-Backend verwendet, muss sich der Cloud Run-Sicherungsdienst im selben Dienstprojekt wie der Backend-Dienst und die serverlose NEG befinden. Die Frontend-Komponenten (Weiterleitungsregel, Zielproxy, URL-Zuordnung) des Load-Balancers können entweder im Hostprojekt, im selben Dienstprojekt wie die Backend-Komponenten oder in einem anderen Dienstprojekt in derselben Umgebung mit freigegebener VPC erstellt werden.

Projektübergreifender Dienstverweis

In diesem Modell befinden sich das Frontend und die URL-Zuordnung des Load-Balancers in einem Host- oder Dienstprojekt. Die Backend-Dienste und Backends des Load-Balancers können auf Projekte in der freigegebenen VPC-Umgebung verteilt werden. Auf projektübergreifende Backend-Dienste kann in einer einzelnen URL-Zuordnung verwiesen werden. Dies wird als projektübergreifender Dienstverweis bezeichnet.

Mit projektübergreifenden Dienstreferenzen können Organisationen einen zentralen Load-Balancer konfigurieren und Traffic an Hunderte von Diensten weiterleiten, die über mehrere verschiedene Projekte verteilt sind. Sie können alle Regeln und Richtlinien für das Traffic-Routing zentral in einer URL-Zuordnung verwalten. Sie können den Load-Balancer auch mit einem einzelnen Satz von Hostnamen und SSL-Zertifikaten verknüpfen. Sie können daher die Anzahl der für die Bereitstellung Ihrer Anwendung erforderlichen Load-Balancer optimieren und die Verwaltungs-, Betriebskosten- und Kontingentanforderungen reduzieren.

Wenn Sie für jedes Ihrer funktionalen Teams unterschiedliche Projekte verwenden, können Sie auch eine Trennung der Rollen innerhalb Ihrer Organisation erreichen. Dienstinhaber können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während Netzwerkteams Load-Balancer in einem anderen Projekt bereitstellen und verwalten können. Beide Dienste können über projektübergreifende Dienstreferenzen verbunden werden.

Dienstinhaber können die Autonomie der Freigabe ihrer Dienste aufrechterhalten und steuern, welche Nutzer über den Load-Balancer auf ihre Dienste zugreifen können. Dies wird durch eine spezielle IAM-Rolle mit der Bezeichnung Nutzer von Compute-Load-Balancer-Diensten (roles/compute.loadBalancerServiceUser) erreicht.

Informationen zum Konfigurieren der freigegebenen VPC für einen internen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Internen Application Load Balancer mit freigegebener VPC einrichten.

Bekannte Einschränkungen beim projektübergreifenden Dienstverweis

  • Sie können nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst regionale Internet-NEG-Backends hat. Alle anderen Backend-Typen werden unterstützt.
  • Google Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie projektübergreifende Dienstreferenzen verwenden, empfehlen wir daher, für alle Projekte in Ihrer Organisation eindeutige Backend-Dienstnamen zu verwenden.

Beispiel 1: Load-Balancer-Frontend und -Backend in verschiedenen Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, bei der das Frontend und die URL-Zuordnung des Load-Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load-Balancers im Dienstprojekt
Frontend und Backend des Load-Balancers in verschiedenen Dienstprojekten

Beispiel 2: Load-Balancer-Frontend im Hostprojekt und Back-Ends in Dienstprojekten

Bei dieser Art der Bereitstellung werden das Frontend und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load-Balancers im Hostprojekt
Frontend und URL-Zuordnung des Load-Balancers im Hostprojekt

Zeitüberschreitungen und Wiederholungsversuche

Interne Application Load Balancer unterstützen die folgenden Zeitüberschreitungstypen:

Zeitlimittyp und Beschreibung Standardwerte Unterstützt benutzerdefinierte Werte
Zeitlimit für Backend-Dienst

Eine Zeitüberschreitung bei Anfrage und Antwort Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte der HTTP-Anfrage an Ihr Backend sendet, bis Ihr Backend das letzte Byte der HTTP-Antwort zurückgibt. Wenn die gesamte HTTP-Antwort nicht innerhalb des Anfrage- oder Antwortzeitlimits an den Load Balancer zurückgegeben wurde, werden die verbleibenden Antwortdaten gelöscht.
  • Für serverlose NEGs in einem Backend-Dienst: 60 Minuten
  • Für alle anderen Backend-Typen in einem Backend-Dienst: 30 Sekunden
Client-HTTP-Keepalive-Zeitlimit
Die maximale Zeitspanne, in der die TCP-Verbindung zwischen einem Client und dem verwalteten Envoy-Proxy des Load Balancers inaktiv sein kann. (Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) 		10 Minuten und 600 Sekunden
Backend-HTTP-Keepalive-Zeitlimit
Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem verwalteten Envoy-Proxy des Load Balancers und einem Backend inaktiv sein kann. (Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) 		10 Minuten und 600 Sekunden

Zeitlimit für Backend-Dienst

Das konfigurierbare Zeitlimit des Backend-Diensts stellt die maximale Zeitspanne dar, die der Load Balancer auf die Verarbeitung einer HTTP-Anfrage durch das Backend wartet und die entsprechende HTTP-Antwort zurückgibt. Mit Ausnahme von serverlosen NEGs beträgt der Standardwert für das Zeitlimit des Backend-Diensts 30 Sekunden.

Wenn Sie beispielsweise eine Datei mit 500 MB herunterladen möchten und der Wert des Zeitlimits für den Backend-Dienst 90 Sekunden beträgt, erwartet der Load Balancer, dass das Backend die gesamte Datei mit 500 MB innerhalb von 90 Sekunden bereitstellt. Das Zeitlimit für den Backend-Dienst kann auch so konfiguriert werden, dass das Backend seine vollständige HTTP-Antwort sendet. Wenn der Load Balancer in dieser Situation zumindest HTTP-Antwortheader erhalten hat, sendet er die vollständigen Antwortheader und so viel vom Antwort-Body zurück, wie er innerhalb des Zeitlimits für den Backend-Dienst erhalten konnte.

Sie sollten das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festlegen, von der Sie erwarten, dass Ihr Backend sie zur Verarbeitung einer HTTP-Antwort benötigt. Sie sollten das Zeitlimit für den Backend-Dienst erhöhen, wenn die auf Ihrem Backend ausgeführte Software mehr Zeit benötigt, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben.

Das Zeitlimit für den Backend-Dienst akzeptiert Werte zwischen 1 und 2,147,483,647 Sekunden. Größere Werte sind jedoch keine praktischen Konfigurationsoptionen. Google Cloud garantiert nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

Bei WebSocket-Verbindungen, die mit internen Application Load Balancern verwendet werden, folgen aktive WebSocket-Verbindungen nicht der Zeitüberschreitung des Backend-Dienstes. Inaktive WebSocket-Verbindungen werden nach der Zeitüberschreitung des Backend-Dienstes geschlossen.

Google Cloud startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgabenneustarts oder -ersetzungen beendet werden.

Verwenden Sie eine der folgenden Methoden, um das Zeitlimit des Backend-Dienstes zu konfigurieren:

Client-HTTP-Keepalive-Zeitlimit

Das Client-HTTP-Keepalive-Zeitlimit stellt die maximale Zeitspanne dar, die eine TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy inaktiv sein kann. Der Zeitüberschreitungswert des Client-HTTP-Keepalives beträgt 600 Sekunden.

Ein HTTP-Keepalive-Zeitlimit wird auch als TCP-Leerlaufzeitlimit bezeichnet.

Das Client-HTTP-Zeitlimit des Load Balancers sollte größer sein als das HTTP Keepalive-Zeitlimit (TCP inaktiv), das von nachgelagerten Clients oder Proxys verwendet wird. Wenn ein nachgelagerter Client ein größeres HTTP Keepalive-Zeitlimit (TCP inaktiv) hat als das HTTP Keepalive-Zeitlimit des Clients des Load Balancers, kann eine Race-Bedingung auftreten. Aus Sicht eines nachgelagerten Clients kann eine bestehende TCP-Verbindung länger als der Load Balancer inaktiv sein. Das bedeutet, dass der nachgelagerte Client Pakete senden kann, nachdem der Load Balancer die TCP-Verbindung als geschlossen betrachtet. In diesem Fall antwortet der Load Balancer mit einem TCP-Rücksetzpaket (RST).

HTTP-Keepalive-Zeitlimit des Back-Ends

Interne Application Load Balancer sind Proxys, die eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy und eine zweite TCP-Verbindung zwischen dem Envoy-Proxy und Ihren Back-Ends verwenden.

Die sekundären TCP-Verbindungen des Load Balancers werden möglicherweise nicht nach jeder Anfrage geschlossen. Sie können offen bleiben, um mehrere HTTP-Anfragen und -Antworten zu verarbeiten. Das Backend-HTTP-Keepalive-Zeitlimit definiert das TCP-Leerlaufzeitlimit zwischen dem Load Balancer und Ihren Backends. Das Backend-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. Das Backend-Keepalive-Zeitlimit des Load Balancers sollte unter dem Keepalive-Zeitlimit liegen, das von Software verwendet wird, die auf Ihren Backends ausgeführt wird. Dadurch wird eine Race-Bedingung vermieden, bei der das Betriebssystem Ihrer Back-Ends TCP-Verbindungen mit einem TCP-Zurücksetzen (RST) schließen kann. Da das Backend-Keepalive-Zeitlimit für den Load-Balancer nicht konfigurierbar ist, müssen Sie Ihre Backend-Software so konfigurieren, dass der HTTP-Keepalive-Zeitlimit (TCP inaktiv) größer als 600 Sekunden ist.

In der folgenden Tabelle sind die Änderungen aufgeführt, die zum Ändern der Keepalive-Zeitüberschreitungswerte für häufig verwendete Webserversoftware erforderlich sind.

Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Wiederholungsversuche

Zum Konfigurieren von Wiederholungsversuchen können Sie in der URL-Zuordnung eine Wiederholungsrichtlinie verwenden. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 24 Stunden.

Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt.

HTTP-POST-Anfragen werden nicht wiederholt.

Bei wiederholten Requests wird nur ein Log-Eintrag für die endgültige Antwort generiert.

Weitere Informationen finden Sie unter Logging und Monitoring für Application Load Balancer.

Auf verbundene Netzwerke zugreifen

Zugriff auf einen internen Application Load Balancer in Ihrem VPC-Netzwerk erhalten Sie über ein verbundenes Netzwerk mithilfe von:

  • VPC-Netzwerk-Peering
  • Cloud VPN und Cloud Interconnect

Ausführliche Beispiele finden Sie unter Interne Application Load Balancer und verbundene Netzwerke.

Failover

Wenn ein Backend fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Backends weitergeleitet.

In der folgenden Tabelle wird das Failover-Verhalten in den einzelnen Modi beschrieben:

Load-Balancer-Modus Failover-Verhalten Verhalten, wenn alle Back-Ends fehlerhaft sind
Regionsübergreifender interner Application Load Balancer

Automatisches Failover auf fehlerfreie Backends in derselben Region oder in anderen Regionen.

Der Traffic wird anhand der konfigurierten Trafficverteilung auf fehlerfreie Backends verteilt, die sich über mehrere Regionen erstrecken.

 Gibt HTTP 503 zurück
Regionaler interner Application Load Balancer

Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.

Der Envoy-Proxy sendet Traffic an fehlerfreie Backends in einer Region anhand der konfigurierten Trafficverteilung.

 Gibt HTTP 503 zurück

Hochverfügbarkeit und regionsübergreifender Failover

Sie können einen regionenübergreifenden internen Application Load Balancer in mehreren Regionen einrichten, um folgende Vorteile zu erhalten:

  1. Wenn der regionenübergreifende interne Application Load Balancer in einer Region ausfällt, leiten die DNS-Routingrichtlinien den Traffic an einen regionenübergreifenden internen Application Load Balancer in einer anderen Region weiter.

    Das Bereitstellungsbeispiel für Hochverfügbarkeit zeigt Folgendes:

    • Ein regionenübergreifender interner Application Load Balancer mit virtueller Frontend-IP-Adresse (VIP) in den Regionen RegionA und RegionB in Ihrem VPC-Netzwerk. Die Clients befinden sich in der Region RegionA.
    • Sie können den Load Balancer über Frontend-VIPs aus zwei Regionen zugänglich machen und mit DNS-Routingrichtlinien die optimale VIP an Ihre Clients zurückgeben. Verwenden Sie Routingrichtlinien für die Standortbestimmung, wenn Ihre Clients die VIP verwenden sollen, die geografisch am nächsten liegt.
    • DNS-Routingrichtlinien können erkennen, ob eine VIP während eines regionalen Ausfalls nicht antwortet, und die nächste optimale VIP an Ihre Clients zurückgeben, damit Ihre Anwendung auch bei regionalen Ausfällen verfügbar bleibt.
    Bereitstellung mit Hochverfügbarkeit für regionsübergreifenden internen Application Load Balancer.
    Regionenübergreifender interner Application Load Balancer mit Hochverfügbarkeitsbereitstellung (zum Vergrößern klicken) Vergrößern).

  2. Wenn Backends in einer bestimmten Region ausfallen, wird der regionenübergreifende interne Traffic des Application Load Balancers ordnungsgemäß auf die Backends in einer anderen Region übertragen.

    Das Beispiel für die regionenübergreifende Failover-Bereitstellung zeigt Folgendes:

    • Ein regionenübergreifender interner Application Load Balancer mit einer Frontend-VIP-Adresse in der Region RegionA Ihres VPC-Netzwerks. Ihre Clients befinden sich ebenfalls in der Region RegionA.
    • Ein globaler Backend-Dienst, der auf die Backends in den Google Cloud-Regionen RegionA und RegionB verweist.
    • Wenn die Backends in der Region RegionA ausfallen, wird der Traffic auf die Region RegionB umgeleitet.
    Regionenübergreifender interner Application Load Balancer mit einer regionenübergreifenden Failover-Bereitstellung.
    Regionenübergreifender interner Application Load Balancer mit regionsübergreifender Failover-Bereitstellung (Zum Vergrößern klicken).

WebSocket-Unterstützung

HTTP(S)-basierte Load Balancer von Google Cloud bieten eingebaute Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Backend verwenden. Der Load-Balancer benötigt zum Weiterleiten von WebSocket-Verbindungen über einen Proxy keine Konfiguration.

Das WebSocket-Protokoll bietet einen Vollduplex-Kommunikationskanal zwischen Clients und Servern. Durch eine HTTP(S)-Anfrage wird der Kanal initiiert. Ausführliche Informationen zum Protokoll finden Sie unter RFC 6455.

Wenn der Load-Balancer eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client gefolgt von einer erfolgreichen Upgrade-Antwort der Back-End-Instanz erkennt, leitet er bidirektionalen Traffic für die Dauer der aktuellen Verbindung über einen Proxy weiter. Wenn die Back-End-Instanz keine erfolgreiche Upgrade-Antwort zurückgibt, schließt der Load-Balancer die Verbindung.

Die Sitzungsaffinität für WebSockets funktioniert wie für jede andere Anfrage. Weitere Informationen finden Sie unter Sitzungsaffinität.

gRPC-Unterstützung

gRPC ist ein Open Source-Framework für Remoteprozeduraufrufe. Es basiert auf dem HTTP/2-Standard. Anwendungsfälle für gRPC sind:

  • Hoch skalierbare, verteilte Systeme mit geringer Latenz
  • Entwicklung mobiler Clients, die mit einem Cloud-Server kommunizieren
  • Entwurf neuer Protokolle, die genau, effizient und sprachunabhängig sein müssen
  • Layerdesign, um Erweiterung, Authentifizierung und Protokollierung zu ermöglichen

Um gRPC mit Ihren Google Cloud-Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. So gehen Sie dazu vor:

  1. Konfigurieren Sie einen HTTPS-Load-Balancer.
  2. Wählen Sie HTTP/2 als Protokoll vom Load-Balancer zu den Back-Ends aus.

Der Load-Balancer verhandelt HTTP/2 mit Clients als Teil des SSL-Handshakes und verwendet dazu die ALPN TLS-Erweiterung.

Der Load-Balancer kann mit einigen Clients weiter HTTPS aushandeln oder unsichere HTTP-Anfragen auf einem Load-Balancer akzeptieren, der für die Verwendung von HTTP/2 zwischen dem Load-Balancer und den Backend-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Sie müssen TLS auf Ihren Back-Ends aktivieren. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Zielproxy nur TLS 1.0, 1.1, 1.2 und 1.3, wenn SSL-Requests von Clients beendet werden.

Wenn der interne Application Load Balancer HTTPS als Backend-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 an das Backend aushandeln.

Beschränkungen

  • Es kann nicht garantiert werden, dass eine Anfrage von einem Client in einer Zone der Region an ein Backend gesendet wird, das sich in derselben Zone wie der Client befindet. Die Sitzungsaffinität reduziert nicht die Kommunikation zwischen Zonen.

  • Interne Application Load Balancer sind nicht mit den folgenden Features kompatibel:

  • Ein interner Application Load Balancer unterstützt HTTP/2 nur über TLS.

  • Clients, die eine Verbindung zu einem internen Application Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. HTTP 1.0 wird nicht unterstützt.

  • Von Google Cloud wird keine Warnung ausgegeben, wenn das Nur-Proxy-Subnetz keine IP-Adressen mehr hat.

  • Die interne Weiterleitungsregel, die Ihr interner Application Load Balancer verwendet, muss genau einen Port haben.

  • Interne Application Load Balancer unterstützen Cloud Trace nicht.

  • Wenn Sie einen internen Application Load Balancer mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an alle anderen Cloud Run-Dienste senden, die in einem anderen Dienstprojekte in derselben freigegebenen VPC-Umgebung bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.

  • Google Cloud kann nicht garantieren, dass eine zugrunde liegende TCP-Verbindung während des gesamten festgelegten Zeitlimits für den Backend-Dienst geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

Nächste Schritte