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:

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

    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. Es kann sein, muss aber nicht. 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.

    Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

    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.

  • 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 (numRetries) konfiguriert werden. Ohne eine Wiederholungsrichtlinie sind Anfragen standardmäßig auf einen Versuch beschränkt. Die Standardbedingung für den Wiederholungsversuch ist gateway-error.

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

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