Internes HTTP(S)-Load-Balancing

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 in Compute Engine, Google Kubernetes Engine (GKE) und Cloud Run 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), Cloud Run-Anwendungen 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.

Dreistufige Webdienste mit globalem Zugriff

Wenn Sie den globalen Zugriff aktivieren, können sich Ihre Client-VMs auf Webebene in anderen Regionen befinden.

In diesem Beispiel für eine Anwendung mit mehreren Ebenen wird Folgendes gezeigt:

  • Eine global verfügbare internetorientierte Webebene, bei der der Traffic mit HTTP(S)-Load-Balancing verteilt wird
  • Eine interne Back-End-Datenbankstufe mit Load-Balancing in der Region us-east1, auf die von der globalen Webebene zugegriffen wird.
  • Eine Client-VM, die Teil der Webebene in der Region europe-west1 ist, die auf die interne Datenbankebene mit Load-Balancing in us-east1 zugreift.
Webanwendung mit drei Ebenen und HTTP(S) -Load-Balancing, globalem Zugriff und internem HTTP(S) -Load-Balancing.
Dreistufige Webanwendung mit HTTP(S)-Load-Balancing, globalem Zugriff und internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)

Load-Balancing mit Hybridkonnektivität

Cloud Load Balancing unterstützt Load-Balancing-Traffic zu Endpunkten, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere öffentliche Clouds, die Sie über Hybridkonnektivität erreichen können.

Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem internen HTTP(S)-Load-Balancer.

Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)
Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)

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 verwenden, um mit HTTP(S)-Nutzerdienstkontrollen auf Google APIs zuzugreifen.

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 mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus jedem Subnetz im selben Netzwerk und in derselben Region stammen. Beachten Sie folgende Bedingungen:

  • Die IP-Adresse kann (nicht erforderlich) 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 REGIONAL_MANAGED_PROXY gesetzt ist.
  • Wenn Sie eine interne IP-Adresse für mehrere Weiterleitungsregeln freigeben möchten, legen Sie das Flag --purpose der IP-Adresse auf SHARED_LOADBALANCER_VIP fest.

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.

Weiterleitungsregeln und globaler Zugriff

Die Weiterleitungsregeln eines internen HTTP(S)-Load-Balancers sind regional, auch wenn der globale Zugriff aktiviert ist. Nachdem Sie den globalen Zugriff aktiviert haben, wird das Flag allowGlobalAccess der regionalen internen Weiterleitungsregel auf true gesetzt.

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

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

Back-Ends und VPC-Netzwerke

Alle Back-Ends müssen sich in demselben VPC-Netzwerk und derselben Region 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 Internes HTTP(S)-Load-Balancing und verbundene Netzwerke.

Back-End-Teilmengeneinstellung

Die Back-End-Teileinstellung ist eine optionale Funktion, die die Leistung und Skalierbarkeit verbessert, indem jeder der Proxyinstanzen eine Teilmenge der Back-Ends zugewiesen wird.

Standardmäßig ist die Back-End-Teileinstellung deaktiviert. Informationen zum Aktivieren dieser Funktion finden Sie unter Back-End-Teileinstellung für internen HTTP(S)-Load-Balancer.

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:

Clientzugriff

Standardmäßig müssen sich Clients in derselben Region wie der Load-Balancer befinden. Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist. Sie können den globalen Zugriff aktivieren, damit Clients aus beliebigen Regionen auf Ihren Load-Balancer zugreifen können.

Interner HTTP-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)
Interner HTTP(S)-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)

In der folgenden Tabelle wird der Clientzugriff 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

Das interne HTTP(S)-Load-Balancing unterstützt 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, das interne HTTP(S)-Load-Balancing 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 Front-End-Komponenten Back-End-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 externe 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 Back-End-Dienste und Back-Ends (Instanzgruppen oder NEGs) im selben Dienstprojekt wie die Front-End-Komponenten.

  • Erstellen Sie Back-End-Dienste und Back-Ends (Instanzgruppen oder NEGs) in so vielen Dienstprojekten wie nötig. Eine einzelne URL-Zuordnung kann auf Back-End-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet.
  • Jeder Back-End-Dienst muss im selben Projekt wie die Back-Ends definiert werden, auf die er verweist. Mit den Back-End-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Back-End-Dienst definiert werden.

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

Clients können auf einen internen HTTP(S)-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.

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

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

Projektübergreifender Dienstverweis

In diesem Modell befinden sich das Front-End und die URL-Zuordnung des Load-Balancers in einem Host- oder Dienstprojekt. Die Back-End-Dienste und Back-Ends des Load-Balancers können auf Projekte in der freigegebenen VPC-Umgebung verteilt werden. Auf projektübergreifende Back-End-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 erreicht, die als IAM-Rolle des Load-Balancer-Dienstnutzers bezeichnet wird.

Informationen zum Konfigurieren der freigegebenen VPC für einen internen HTTP(S)-Load-Balancer (mit und ohne projektübergreifendem Dienstverweis) finden Sie unter Internen HTTP(S)-Load-Balancer mit freigegebener VPC einrichten.

Beispiel 1: Load-Balancer-Front-End und -Back-End in verschiedenen Dienstprojekten

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

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

Front-End und URL-Zuordnung des Load-Balancers im Dienstprojekt
Front-End und Back-End des Load-Balancers in verschiedenen Dienstprojekten

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

Bei dieser Art der Bereitstellung werden das Front-End und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Back-End-Dienste (und Back-Ends) in Dienstprojekten erstellt.

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

Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt
Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt

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

In diesem Modell befinden sich alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt. Dieses Bereitstellungsmodell wird von allen HTTP(S)-Load-Balancern unterstützt.

Der Load-Balancer verwendet IP-Adressen und Subnetze aus dem Hostprojekt.

Interner HTTP(S)-Load-Balancer in einem freigegebenen VPC-Netzwerk
Interner HTTP(S)-Load-Balancer in einem freigegebenen VPC-Netzwerk

Zeitüberschreitungen und Wiederholungsversuche

Internes HTTP(S)-Load-Balancing hat drei verschiedene Zeitlimittypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das sich danach richtet, 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.

    Wenn Sie beispielsweise eine Datei mit 500 MB herunterladen möchten und der Wert des Zeitlimits für den Back-End-Dienst der Standardwert von 30 Sekunden ist, erwartet der Load-Balancer, dass das Back-End die gesamte Datei mit 500 MB innerhalb von 30 Sekunden bereitstellt. Das Zeitlimit für den Back-End-Dienst kann auch so konfiguriert werden, dass es nicht lang genug ist, damit das Back-End seine vollständige HTTP-Antwort senden kann. 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 Back-End-Dienst erhalten konnte.

    Das Zeitlimit für den Back-End-Dienst sollte auf die maximal mögliche Zeit vom ersten Byte der Anfrage bis zum letzten Byte der Antwort für die Interaktion zwischen Envoy und Ihrem Back-End festgelegt werden. Wenn Sie WebSockets verwenden, sollte das Zeitlimit des Back-End-Dienstes auf die maximale Dauer eines WebSockets, inaktiv oder aktiv, festgelegt werden.

    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.

    Das von Ihnen festgelegte Zeitlimit für den Back-End-Dienst ist ein Best-Effort-Ziel. Dabei ist nicht garantiert, dass die zugrunde liegenden TCP-Verbindungen für die Dauer dieses Zeitlimits geöffnet bleiben.

    Sie können das Zeitlimit für den Back-End-Dienst auf einen beliebigen Wert festlegen. Wenn Sie ihn jedoch auf einen Wert über einen Tag hinaus (86.400 Sekunden) festlegen, bedeutet dies nicht, dass der Load-Balancer so lange eine TCP-Verbindung beibehält. Google startet Envoy-Proxys regelmäßig für Softwareupdates und routinemäßige Wartungen neu. Dies wird durch das Zeitlimit des Back-End-Dienstes nicht überschrieben. Je länger Sie das Zeitlimit des Back-End-Diensts festlegen, desto wahrscheinlicher ist es, dass Google eine TCP-Verbindung für die Envoy-Wartung beendet. Wir empfehlen Ihnen, eine Wiederholungslogik zu implementieren, um die Auswirkungen solcher Ereignisse zu reduzieren.

    Das Zeitlimit des Back-End-Diensts ist keine HTTP-Leerlaufzeitüberschreitung (Keepalive-Zeitüberschreitung). Es kann vorkommen, dass die Ein- und Ausgabe (IO) des Back-Ends aufgrund eines langsamen Clients, z. B. ein Browser mit langsamer Verbindung, blockiert wird. Diese Wartezeit wird nicht auf das Zeitlimit des Back-End-Diensts angerechnet.

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

    • Google Cloud Console: Ändern Sie das Feld Zeitlimit des Back-End-Diensts des Load-Balancers.
    • Google Cloud CLI: Verwenden Sie den Befehl gcloud compute backend-services update, um den Parameter --timeout der Back-End-Dienstressource zu ändern.
    • API: Ändern Sie den Parameter timeoutSec für die Back-End-Dienstressource global oder regional.

  • Ein HTTP-Keepalive-Zeitlimit, dessen Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Dieser Wert kann nicht konfiguriert werden, indem Ihr Back-End-Dienst geändert wird. 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 veranschaulicht, die erforderlich sind, um Keepalive-Zeitüberschreitungen für häufig verwendete 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 inaktivem Stream, deren Wert unveränderlich bei 5 Minuten (300 Sekunden) liegt. Dieser Wert ist nicht konfigurierbar. HTTP-Streams werden nach 5 Minuten ohne Aktivität inaktiv.

Neuversuche

Wiederholungsversuche können mithilfe einer Wiederholungsrichtlinie in der URL-Zuordnung konfiguriert werden. 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-502-, 503- oder 504-Antworten führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Dieses Standardverhalten entspricht retryConditions=["gateway-error"].

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

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 Back-End-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Back-End-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 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

  • 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:

  • 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.

  • Wenn Sie das interne HTTP(S)-Load-Balancing mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an andere Cloud Run-Dienste senden, die in anderen Dienstprojekten in derselben freigegebenen VPC-Umgebung bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.

Nächste Schritte