Internes HTTP(S)-Load-Balancing

Das interne HTTP(S)-Load-Balancing von Google Cloud ist ein proxy-basierter, regionaler Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren können.

Das interne HTTP(S)-Load-Balancing verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die auf Compute Engine und Google Kubernetes Engine (GKE) gehostet werden. Auf den Load-Balancer kann nur in der ausgewählten Region Ihres VPC-Netzwerks (Virtual Private Cloud) mit einer internen IP-Adresse zugegriffen werden.

Das interne HTTP(S)-Load-Balancing ist ein verwalteter Dienst, der auf dem Open-Source-Proxy von Envoy basiert. Dadurch werden zahlreiche Funktionen zur Trafficsteuerung anhand von HTTP(S)-Parametern ermöglicht. Nachdem der Load-Balancer konfiguriert wurde, werden automatisch Envoy-Proxys zugewiesen, um Ihre Trafficanforderungen zu erfüllen.

Auf übergeordneter Ebene besteht ein interner HTTP(S)-Load-Balancer aus Folgendem:

  • Einer internen IP-Adresse, an die Clients Traffic senden. Nur Clients, die sich in derselben Region befinden wie der Load-Balancer, können auf diese IP-Adresse zugreifen. Interne Clientanfragen bleiben in Ihrem Netzwerk und in Ihrer Region.
  • Einem oder mehreren Back-End-Diensten, an die der Load-Balancer Traffic weiterleitet. Back-Ends können Compute Engine-VMs, Gruppen von Compute Engine-VMs (über Instanzgruppen) oder GKE-Knoten (über Netzwerk-Endpunktgruppen [NEGs]) sein. Diese Back-Ends müssen sich in derselben Region wie der Load-Balancer befinden.
Interne Dienste mit auf Layer 7 beruhendem Load-Balancing (zum Vergrößern klicken)
Interne Dienste mit auf Layer 7 basierendem Load-Balancing (zum Vergrößern klicken)

Informationen zu Einschränkungen, die für das interne HTTP(S)-Load-Balancing gelten, finden Sie im Abschnitt Einschränkungen.

Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:

Anwendungsfälle

Das interne HTTP(S)-Load-Balancing ist für viele Anwendungsfälle geeignet. Dieser Abschnitt enthält einige allgemeine Beispiele. Weitere Beispiele finden Sie unter Anwendungsfälle für die Trafficverwaltung.

Dreistufige Webdienste

Sie können das interne HTTP(S)-Load-Balancing verwenden, um herkömmliche dreistufige Webdienste zu unterstützen. Das folgende Beispiel zeigt, wie Sie mit drei Arten von Google Cloud-Load-Balancern drei Stufen skalieren können. Auf jeder Stufe hängt die Art des Load-Balancers von Ihrem Traffictyp ab:

  • Webstufe: Der Traffic geht über das Internet ein und wird mithilfe eines externen HTTP(S)-Load-Balancers entsprechend verteilt.

  • Anwendungsstufe: Die Anwendungsstufe wird mithilfe eines regionalen internen HTTP(S)-Load-Balancers skaliert.

  • Datenbankstufe: Die Datenbankstufe wird mithilfe eines internen TCP/UDP-Load-Balancers skaliert.

Das Diagramm zeigt, wie sich der Traffic durch die Ebenen bewegt:

  1. Ein externer HTTP(S)-Load-Balancer verteilt den Traffic aus dem Internet an eine Reihe von Web-Front-End-Instanzgruppen in verschiedenen Regionen.
  2. Diese Front-Ends senden den HTTP(S)-Traffic an eine Reihe von regionalen, internen HTTP(S)-Load-Balancern (Gegenstand dieser Übersicht).
  3. Die internen HTTP(S)-Load-Balancer verteilen den Traffic auf Middleware-Instanzgruppen.
  4. Diese Middleware-Instanzgruppen senden den Traffic an interne TCP/UDP-Load-Balancer, die den Traffic auf Datenspeichercluster verteilen.
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung (zum Vergrößern klicken)
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung

Load-Balancing mit pfadbasiertem Routing

Ein häufiger Anwendungsfall ist das Load-Balancing zwischen verschiedenen Diensten. In diesem Beispiel fordert ein interner Client mithilfe derselben Basis-URL mygcpservice.internal und den Pfaden /video und /images Video- und Bildinhalte an.

Die URL-Zuordnung des internen HTTP(S)-Load-Balancers gibt an, dass Anfragen an den Pfad /video an den Back-End-Dienst für Videos und Anfragen an den Pfad /images an den Back-End-Dienst für Bilder gesendet werden. Im folgenden Beispiel werden die Back-End-Dienste für Videos und Bilder mithilfe von Compute Engine-VMs bereitgestellt. Sie können jedoch auch mithilfe von GKE-Pods bereitgestellt werden.

Wenn ein interner Client eine Anfrage an die interne IP-Adresse des Load-Balancers sendet, wertet der Load-Balancer die Anfrage gemäß dieser Logik aus und sendet sie an den richtigen Back-End-Dienst.

Das folgende Diagramm veranschaulicht diesen Anwendungsfall.

Interne (Mikro-)Dienste mit auf Layer 7 beruhendem Load-Balancing (zum Vergrößern klicken)
Interne (Mikro-)Dienste mit auf Layer 7 basierendem Load-Balancing

Legacy-Dienste modernisieren

Das interne HTTP(S)-Load-Balancing kann ein wirksames Tool zur Modernisierung von Legacy-Anwendungen sein.

Ein Beispiel für eine Legacy-Anwendung ist eine umfangreiche monolithische Anwendung, die sich nicht einfach aktualisieren lässt. In diesem Fall können Sie vor der Legacy-Anwendung einen internen HTTP(S)-Load-Balancer bereitstellen. Anschließend können Sie die Trafficsteuerungsfunktionen des Load-Balancers verwenden, um einen Teil des Traffics an neue Mikrodienste weiterzuleiten, die die von Ihrer Legacy-Anwendung bereitgestellten Funktionen ersetzen.

Zuerst würden Sie die URL-Zuordnung des Load-Balancers so konfigurieren, dass standardmäßig der gesamte Traffic zur Legacy-Anwendung weitergeleitet wird. Somit wird das bereits gegebene Verhalten beibehalten. Wenn Ersatzdienste entwickelt werden, würden Sie die URL-Zuordnung aktualisieren, um Teile des Traffics an diese Ersatzdienste weiterzuleiten.

Angenommen, Ihre Legacy-Anwendung umfasst eine Funktion zur Verarbeitung von Videos, die bereitgestellt wird, wenn interne Clients Anfragen an /video senden. So könnten Sie diesen Videodienst herauslösen und in einen separaten Mikrodienst aufnehmen:

  1. Fügen Sie vor Ihrer Legacy-Anwendung ein internes HTTP(S)-Load-Balancing hinzu.
  2. Erstellen Sie einen Ersatzmikrodienst zur Verarbeitung von Videos.
  3. Aktualisieren Sie die URL-Zuordnung des Load-Balancers, sodass alle Anfragen an den Pfad /video an den neuen Mikrodienst und nicht an die Legacy-Anwendung weitergeleitet werden.

Im Zuge der Entwicklung zusätzlicher Ersatzdienste würden Sie die URL-Zuordnung fortlaufend aktualisieren. Im Laufe der Zeit würden weniger Anfragen an die Legacy-Anwendung weitergeleitet. Schließlich würden Ersatzdienste für alle Funktionen der Legacy-Anwendung zur Verfügung stehen. An diesem Punkt können Sie Ihre Legacy-Anwendung entfernen.

Private Service Connect

Sie können ein internes HTTP(S)-Load-Balancing verwenden, um Anfragen an unterstützte regionale Google APIs und -Dienste zu senden. Weitere Informationen finden Sie unter Private Service Connect.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in GKE erstellen, empfehlen wir die Verwendung des integrierten GKE-Ingress-Controller, der Google Cloud-Load-Balancer im Namen von GKE-Nutzern bereitstellt. Dies ist mit der auf dieser Seite beschriebenen eigenständigen Load-Balancing-Architektur identisch, mit dem Unterschied, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird.

Zugehörige GKE-Dokumentation:

Architektur und Ressourcen

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen internen HTTP(S)-Load-Balancer erforderlich sind.

Komponenten des internen HTTP(S)-Load-Balancings (zum Vergrößern klicken)
Komponenten des internen HTTP(S)-Load-Balancings

Jeder interne HTTP(S)-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 HTTP(S)-Load-Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Alle internen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk haben dasselbe Nur-Proxy-Subnetz, da alle internen HTTP(S)-Load-Balancer in der Region und dem VPC-Netzwerk einen Pool von Envoy-Proxys teilen. Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Back-End-VMs bzw. Endpunkte aller internen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen HTTP(S)-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

Eine intern verwaltete Weiterleitungsregel gibt eine interne IP-Adresse, einen Port und einen regionalen HTTP(S)-Ziel-Proxy an. 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 internen HTTP(S)-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 interne IP-Adresse der Weiterleitungsregel kann aus jedem Subnetz (im selben Netzwerk und in derselben Region) stammen, wobei das Flag --purpose auf PRIVATE gesetzt ist. Hinweis:

  • Die IP-Adresse kann (muss aber nicht) aus demselben Subnetz wie die Back-End-Instanzgruppen stammen.
  • Die IP-Adresse darf nicht aus dem reservierten Nur-Proxy-Subnetz stammen, dessen Flag --purpose auf INTERNAL_HTTPS_LOAD_BALANCER gesetzt ist.

Jede externe Weiterleitungsregel, die Sie in einem internen HTTP(S)-Load-Balancer verwenden, kann auf genau einen TCP-Port verweisen. Verwenden Sie für HTTP-Load-Balancer entweder Port 80 oder 8080 und für HTTPS-Load-Balancer Port 443.

Zielproxy

Ein regionaler 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 Back-End-Instanz erfasst möglicherweise diese Adresse sowie die eigene IP-Adresse der Back-End-Instanz.

SSL-Zertifikate

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll, das in SSL-Zertifikaten zum Schutz der Netzwerkkommunikation verwendet wird.

Google Cloud verwendet SSL-Zertifikate, um für einen Load-Balancer Datenschutz und Sicherheit von einem Client bereitzustellen. Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

Weitere Informationen zu SSL-Zertifikaten finden Sie hier:

URL-Zuordnung

Der HTTP(S)-Proxy verwendet eine regionale URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Anhand dieser Entscheidung leitet der Proxy Clientanfragen an bestimmte regionale Back-End-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.

Back-End-Dienst

Ein regionaler Back-End-Dienst verteilt Anfragen an fehlerfreie Back-Ends: Instanzgruppen mit Compute Engine-VMs, NEGs mit GKE-Containern oder Private Service Connect-NEGs, die auf unterstützte Google APIs und Google-Dienste verweisen.

Back-End-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.

Mindestens ein Back-End muss mit dem Back-End-Dienst verbunden sein. Da der Bereich eines internen HTTP(S)-Load-Balancers regional und nicht global ist, müssen sich Clients und Back-End-VMs oder Endpunkte alle in derselben Region befinden. Back-Ends können Instanzgruppen oder NEGs in einer beliebigen der folgenden Konfigurationen sein:

  • Verwaltete Instanzgruppen (zonal oder regional)
  • Nicht verwaltete Instanzgruppen (zonal)
  • Netzwerk-Endpunktgruppen (zonal)

Sie können nicht sowohl Instanzgruppen als auch NEGs für denselben Back-End-Dienst verwenden.

Systemdiagnose

Eine regionale Systemdiagnose überwacht regelmäßig die Bereitschaft Ihrer Back-Ends. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können.

Firewallregeln

Für einen internen HTTP(S)-Load-Balancer sind die folgenden Firewallregeln erforderlich:

Zeitlimits und Wiederholungsversuche

Das Zeitlimit für den Back-End-Dienst ist ein Anfrage/Antwort-Zeitlimit für HTTP(S)-Traffic. Das Zeitlimit definiert, wie lange der Load-Balancer wartet, bis ein Back-End eine vollständige Antwort auf eine Anfrage zurückgibt.

Wenn das Zeitlimit für den Back-End-Dienst beispielsweise auf den Standardwert von 30 Sekunden festgelegt ist, haben die Back-Ends 30 Sekunden Zeit, um auf Anfragen zu antworten. Der Load-Balancer wiederholt die HTTP-GET-Anfrage einmal, wenn das Back-End die Verbindung trennt oder das Zeitlimit überschritten wird, bevor Antwortheader an den Load-Balancer gesendet werden. Wenn das Back-End Antwortheader sendet oder die an das Back-End gesendete Anfrage keine HTTP-GET-Anfrage ist, wiederholt der Load-Balancer die Anfrage nicht. Wenn das Back-End überhaupt nicht antwortet, gibt der Load-Balancer eine HTTP 5xx-Antwort an den Client zurück. Ändern Sie für diese Load-Balancer den Zeitlimitwert, wenn Sie mehr oder weniger Zeit für die Beantwortung der Anfragen durch die Back-Ends einplanen möchten.

Internes HTTP(S)-Load-Balancing hat drei verschiedene Zeitlimittypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das angibt, wie lange der Load-Balancer auf eine vollständige HTTP-Antwort vom Back-End wartet. Der Standardwert für das Zeitlimit des Back-End-Diensts beträgt 30 Sekunden. Zulässig sind Zeitlimitwerte im Bereich von 1 bis 2.147.483.647 Sekunden.

    Unter diesen Umständen sollten Sie dieses Zeitlimit eventuell erhöhen:

    • Sie erwarten, dass HTTP-Antworten von einem Back-End länger dauern.
    • Die Verbindung wurde zu einem WebSocket hochgestuft.

Beim Senden von WebSocket-Traffic über den Load-Balancer wird das Zeitlimit für den Back-End-Dienst als die maximale Zeit verstanden, die eine WebSocket-Verbindung geöffnet sein kann – im Leerlauf oder aktiv. Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

  • Eine TCP-Sitzungszeitüberschreitung, deren Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Diese Sitzungszeitüberschreitung wird manchmal als Keepalive- oder Leerlaufzeitüberschreitung bezeichnet. Ihr Wert kann nicht über eine Änderung im Back-End-Dienst konfiguriert werden. Sie müssen die von den Back-Ends verwendete Webserversoftware so konfigurieren, dass die darin angegebene Keepalive-Zeitüberschreitung länger als 600 Sekunden ist, damit Verbindungen nicht vorzeitig vom Back-End geschlossen werden. Dieses Zeitlimit gilt nicht für WebSockets.

In dieser Tabelle werden die Änderungen dargestellt, die erforderlich sind, um Keepalive-Zeitlimits bei häufig verwendeter Webserversoftware zu ändern:

Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • Eine Zeitüberschreitung bei Inaktivität, deren Wert dem Zeitlimit des Back-End-Diensts entspricht. HTTP-Streams und Websocket-Verbindungen werden inaktiv, wenn während dieser Dauer keine Aktivität vorhanden ist.
  • Der Load-Balancer wiederholt fehlerhafte GET-Anfragen unter bestimmten Umständen, etwa wenn das Zeitlimit des Back-End-Diensts abgelaufen ist. Fehlerhafte POST-Anfragen werden nicht wiederholt. Es gibt maximal zwei Wiederholungsversuche. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

    Weitere Informationen finden Sie unter Logging und Monitoring für HTTP(S)-Load-Balancing.

    Auf verbundene Netzwerke zugreifen

    Zugriff auf einen internen HTTP(S)-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 Internes HTTP(S)-Load-Balancing und verbundene Netzwerke.

    Failover

    Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Wenn alle Back-Ends fehlerhaft sind, gibt der Load-Balancer die Antwort HTTP 503 Service Unavailable zurück.

    WebSocket-Unterstützung

    HTTP(S)-basierte Load-Balancer von Google Cloud bieten native Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Back-End 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 Zeitüberschreitung für eine WebSocket-Verbindung hängt vom konfigurierbaren Back-End-Dienst-Zeitlimit des Load-Balancers ab, das standardmäßig 30 Sekunden beträgt. Diese Zeitüberschreitung wird auf WebSocket-Verbindungen unabhängig davon angewendet, ob sie gerade verwendet werden.

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

    Architekturen freigegebener VPCs

    Das interne HTTP(S)-Load-Balancing unterstützt Netzwerke, die eine freigegebene VPC verwenden. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

    Im Kontext des internen HTTP(S)-Load-Balancings gibt es zwei Möglichkeiten, das Load-Balancing in einem freigegebenen VPC-Netzwerk zu konfigurieren. Sie können den Load-Balancer und seine Back-End-Instanzen entweder im Dienstprojekt oder im Hostprojekt erstellen.

    Load-Balancer und Back-Ends in einem Dienstprojekt

    In diesem Modell befinden sich der Load-Balancer und die Back-Ends in einem Dienstprojekt und verwenden IP-Adressen in Subnetzen eines freigegebenen VPC-Netzwerks.

    Dieses Bereitstellungsmodell entspricht typischen Anwendungsfällen für freigegebene VPCs:

    • Wenn Sie die Verantwortung zwischen der Netzwerkverwaltung und der Dienstentwicklung aufteilen, bleiben die Verantwortlichkeiten zwischen Netzwerkadministratoren und Dienstentwicklern klar getrennt.
    • Ermöglicht Netzwerkadministratoren die sichere und effiziente Verwaltung interner IP-Adressen.
    Internes HTTP(S)-Load-Balancing in freigegebenem VPC-Netzwerk
    Internes HTTP(S)-Load-Balancing in freigegebenem VPC-Netzwerk

    Hostprojekt

    Im Hostprojekt:

    Dienstprojekt

    • Der Inhaber des Projekts, der Bearbeiter oder eine detailliertere Rolle (z. B. ein Compute-Administrator) erstellt Back-End-Instanzen.
    • Der Inhaber des Projekts, der Bearbeiter oder eine detailliertere Rolle (z. B. ein Netzwerkadministrator oder Load-Balancer-Administrator) erstellt die Komponenten des Load-Balancers (Weiterleitungsregel, Ziel-HTTP(S)-Proxy, URL-Zuordnung, Back-End-Dienste und Systemdiagnosen).
    • Diese Load-Balancing-Ressourcen und Back-End-Instanzen verweisen auf ein freigegebenes VPC-Netzwerk und Subnetze im Hostprojekt.

    Clients können auf den Load-Balancer zugreifen, wenn sie sich im selben freigegebenen VPC-Netzwerk und in derselben Region wie der Load-Balancer befinden. Clients können sich in einem Dienstprojekt oder im Hostprojekt befinden.

    Informationen zum Konfigurieren eines internen HTTP(S)-Load-Balancers für ein freigegebenes VPC-Netzwerk finden Sie unter Internes HTTP(S)-Load-Balancing mit freigegebener VPC einrichten.

    Load-Balancer und Back-Ends in einem Hostprojekt

    In diesem Modell befinden sich das freigegebene VPC-Netzwerk, die Load-Balancer-Komponenten und die Back-Ends im Hostprojekt. Dieses Modell trennt nicht die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung.

    Die Konfiguration für dieses Modell entspricht der Konfiguration des Load-Balancers in einem eigenständigen VPC-Netzwerk. Führen Sie die Schritte unter Internes HTTP(S)-Load-Balancing einrichten aus.

    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 HTTP(S)-Load-Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 an das Back-End aushandeln.

    Beschränkungen

    • Das interne HTTP(S)-Load-Balancing funktioniert auf regionaler Ebene.

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

    • Das interne HTTP(S)-Load-Balancing ist nicht mit den folgenden Features kompatibel:

    • Beim Erstellen eines internen HTTP(S)-Load-Balancers in einem Host- oder Dienstprojekt in einer freigegebenen VPC:

      • Alle Load-Balancing-Komponenten und Back-Ends müssen sich im selben Projekt befinden, entweder alle in einem Hostprojekt oder alle in einem Dienstprojekt. Sie können beispielsweise die Weiterleitungsregel des Load-Balancers nicht in einem Projekt bereitstellen und Back-End-Instanzen in einem anderen Projekt erstellen.

      • Clients können sich entweder im Hostprojekt, in angehängten Dienstprojekten oder in verbundenen Netzwerken befinden. Clients müssen dasselbe freigegebene VPC-Netzwerk verwenden und sich in derselben Region wie der Load-Balancer befinden.

    • Ein interner HTTP(S)-Load-Balancer unterstützt HTTP/2 nur über TLS.

    • Clients, die eine Verbindung zu einem internen HTTP(S)-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 HTTP(S)-Load-Balancer verwendet, muss genau einen Port haben.

    • Das interne HTTP(S)-Load-Balancing unterstützt Cloud Trace nicht.

    • Interne HTTP(S)-Load-Balancer unterstützen kein VPC-Netzwerk-Peering. Sie müssen die Weiterleitungsregeln und Back-Ends des Load-Balancers im selben VPC-Netzwerk erstellen.

    Nächste Schritte