Interner Proxy-Network Load Balancer – Übersicht

Der regionale interne Proxy-Network Load Balancer von Google Cloud ist ein proxy-basierter regionaler Load Balancer, der auf der Open-Source-Proxy-Software Envoy und dem Andromeda-Netzwerkvirtualisierungs-Stack basiert.

Der interne Proxy-Network Load Balancer ist ein Layer-4-Load-Balancer, mit dem Sie Ihren TCP-Diensttraffic hinter einer regionalen internen IP-Adresse ausführen und skalieren können, auf die nur Clients im selben VPC-Netzwerk oder Clients zugreifen können., die mit Ihrem VPC-Netzwerk verbunden sind. Der Load Balancer beendet zuerst die TCP-Verbindung zwischen dem Client und dem Load Balancer in einem Envoy-Proxy. Der Proxy öffnet eine zweite TCP-Verbindung zu Back-Ends, die in Google Cloud, lokal oder in anderen Cloud-Umgebungen gehostet werden. Weitere Anwendungsfälle finden Sie unter Proxy-Network Load Balancer.

Betriebsarten

Sie können einen externen Proxy-Network Load Balancer in den folgenden Modi konfigurieren:

  • Regionaler interner Proxy-Network 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.

  • Regionsübergreifender interner Proxy-Network 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.

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

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

    VIP-Adressen aus mehreren Regionen können denselben globalen Backend-Dienst verwenden.
    Clientzugriff Zugriff ist standardmäßig nicht global möglich.
    (Optional) Sie können den globalen Zugriff aktivieren.    		 Zugriff immer global. Clients aus jeder Google Cloud-Region können Traffic an den Load Balancer senden.
    Back-Ends mit Load Balancing 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.    		 Globale Back-Ends.
    Der Load Balancer kann Traffic an Back-Ends in jeder Region senden.
    Hochverfügbarkeit und Failover Automatisches Failover auf fehlerfreie Back-Ends in derselben Region. Automatisches Failover auf fehlerfreie Backends in derselben oder in unterschiedlichen Regionen.

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 Proxy-Network Load Balancer Netzwerk (Proxy) Intern Gibt eine Region an
    Regionsübergreifender interner Proxy-Network Load Balancer Netzwerk (Proxy) 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
    Regionaler interner Proxy-Network Load Balancer INTERNAL_MANAGED Regional
    Regionsübergreifender interner Proxy-Network Load Balancer INTERNAL_MANAGED Global

Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für interne Proxy-Network Load Balancer erforderlich sind.

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen internen Proxy-Network Load Balancer in der Premium-Stufe.

Komponenten des regionalen internen Proxy-Network Load Balancers.
Komponenten des regionalen internen Proxy-Network Load Balancers (zum Vergrößern klicken)

Regionenübergreifend

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

Komponenten des regionsübergreifenden internen Proxy-Network Load Balancers
Komponenten des regionenübergreifenden internen Proxy-Network Load Balancers (zum Vergrößern klicken)

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 einen Envoy-basierten internen Proxy-Network Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen.

In der folgenden Tabelle werden die Anforderungen an Nur-Proxy-Subnetze für interne Proxy-Network Load Balancer beschrieben:

Load-Balancer-Modus Wert des Flags --purpose des Nur-Proxy-Subnetzes
Regionaler interner Proxy-Network 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
Regionsübergreifender interner Proxy-Network 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.

Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Back-End-VM-Instanzen oder Endpunkte aller internen Proxy-Network Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen Proxy-Network Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load Balancers wird durch seine intern verwaltete Weiterleitungsregel definiert.

Weiterleitungsregeln und IP-Adressen

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

IP-Adressspezifikation 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 TCP verwenden. Eine vollständige Liste der unterstützten Protokolle finden Sie im Vergleich der 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 Back-Ends stammen.

Portspezifikation Jede Weiterleitungsregel, die Sie in einem internen Proxy-Network Load Balancer verwenden, kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren.

In der folgenden Tabelle sind die Anforderungen an Weiterleitungsregeln für interne Proxy-Network Load Balancer aufgeführt:

Load-Balancer-Modus Weiterleitungsregel, IP-Adresse und Nur-Proxy-Subnetz --purpose Routing vom Client zum Frontend des Load Balancers
Regionaler interner Proxy-Network Load Balancer

Regional forwardingRules

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 beliebigen Regionen auf Ihren Load Balancer zugreifen können. Backends müssen sich auch in derselben Region wie der Load Balancer befinden.
Regionsübergreifender interner Proxy-Network Load Balancer

Global globalForwardingRules

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 auf den Load Balancer zugreifen können. Back-Ends können sich in mehreren Regionen befinden.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von externen Application Load Balancern verwendet werden, mit VPC-Netzwerken verknüpft werden.

Load-Balancer-Modus VPC-Netzwerkverknüpfung
Regionsübergreifender interner Proxy-Network Load Balancer

Regionaler interner Proxy-Network Load Balancer

Regionale interne IPv4-Adressen befinden sich immer in VPC-Netzwerken. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie das Subnetz angeben, aus dem die interne IP-Adresse übernommen wird. Dieses Subnetz muss sich in derselben Region und im selben VPC-Netzwerk befinden, in der bzw. in dem ein Nur-Proxy-Subnetz erstellt wurde. Es gibt also eine implizite Netzwerkverknüpfung.

Zielproxys

Der interne Proxy-Network Load Balancer beendet TCP-Verbindungen vom Client und erstellt neue Verbindungen zu den Back-Ends. Standardmäßig bleiben die ursprüngliche IP-Adresse des Clients und die Portinformationen nicht erhalten. Sie können diese Informationen jedoch mithilfe des Proxy-Protokolls aufbewahren. Der Zielproxy leitet eingehende Anfragen direkt an den Backend-Dienst des Load-Balancers weiter.

In der folgenden Tabelle sind die Zielproxy APIs aufgeführt, die für interne Proxy-Network Load Balancer erforderlich sind:

Load-Balancer-Modus Zielproxy
Regionaler interner Proxy-Network Load Balancer Regional regionTargetTcpProxies
Regionsübergreifender interner Proxy-Network Load Balancer Global targetTcpProxies

Backend-Dienst

Ein Backend-Dienst leitet eingehenden Traffic an ein oder mehrere verknüpfte Backends weiter. Ein Backend ist entweder eine Instanzgruppe oder eine Netzwerk-Endpunktgruppe. Das Backend enthält Informationen zum Balancing-Modus, um die Vollständigkeit basierend auf Verbindungen zu definieren (oder, nur bei Instanzgruppen-Backends, basierend auf der Auslastung).

Jeder interne Proxy-Network Load Balancer hat eine einzelne Backend-Dienstressource.

In der folgenden Tabelle sind die Anforderungen an den Backend-Dienst für interne Proxy-Network Load Balancer aufgeführt:

Load-Balancer-Modus Typ des Backend-Dienstes
Regionaler interner Proxy-Network Load Balancer Regional regionBackendServices
Regionsübergreifender interner Proxy-Network Load Balancer Global backendServices

Unterstützte Back-Ends

Der Backend-Dienst unterstützt die folgenden Arten von Backends:

Load-Balancer-Modus Unterstützte Backends in einem Backend-Dienst
Instanzgruppen Zonale NEGs Internet-NEGs Serverlose NEGs Hybrid-NEGs Private Service Connect-NEGs GKE
Regionaler interner Proxy-Network Load Balancer
Endpunkte des Typs GCE_VM_IP_PORT		 Nur regionale NEGs Private Service Connect-NEG hinzufügen
Regionsübergreifender interner Proxy-Network Load Balancer
Endpunkte des Typs GCE_VM_IP_PORT		 Private Service Connect-NEG hinzufügen

Alle Back-Ends müssen vom selben Typ sein (Instanzgruppen oder NEGs). Sie können verschiedene Typen von Instanzgruppen-Backends gleichzeitig verwenden. Sie können auch verschiedene Arten von NEG-Backends gleichzeitig verwenden. Sie können jedoch Instanzgruppen- und NEG-Backends nicht zusammen auf demselben Backend-Dienst verwenden.

Sie können zonale und hybride NEGs innerhalb desselben Backend-Dienstes kombinieren.

Sie vermeiden Unterbrechungen für Ihre Nutzer weitgehend, wenn Sie den Verbindungsausgleich bei Backend-Diensten aktivieren. Unterbrechungen dieser Art können auftreten, wenn ein Back-End beendet, manuell entfernt oder durch Autoscaling entfernt wird. Weitere Informationen zum Vermeiden von Dienstunterbrechungen mithilfe des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

Back-Ends und VPC-Netzwerke

  • Bei Instanzgruppen, zonalen NEGs und NEGs mit Hybrid-Konnektivität müssen sich alle Backends im selben Projekt und in derselben Region wie der Backend-Dienst befinden. Ein Load Balancer kann jedoch auf ein Backend verweisen, das ein anderes VPC-Netzwerk im selben Projekt wie der Backend-Dienst verwendet. Diese Funktion befindet sich in der Vorabversion. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder ein Network Connectivity Center-Framework konfiguriert werden.

    Definition des Backend-Netzwerks

    • Bei zonalen und hybriden NEGs geben Sie das VPC-Netzwerk beim Erstellen der NEG explizit an.
    • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
    • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so festgelegt, dass es mit dem VPC-Netzwerk der nic0-Schnittstelle der ersten VM übereinstimmt, die der Instanzgruppe hinzugefügt wird.

    Anforderungen an das Backend-Netzwerk

    Das Netzwerk deines Backends muss eine der folgenden Netzwerkanforderungen erfüllen:

    • Das VPC-Netzwerk des Backends muss genau mit dem VPC-Netzwerk der Weiterleitungsregel übereinstimmen.

    • Das VPC-Netzwerk des Backends muss über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der Weiterleitungsregel verbunden sein. Sie müssen den Austausch von Subnetzrouten konfigurieren, um die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zu ermöglichen, die von den Backend-Instanzen oder Endpunkten verwendet werden.

  • Sowohl das VPC-Netzwerk des Backends als auch das VPC-Netzwerk der Weiterleitungsregel müssen VPC-Spokes auf demselben Network Connectivity Center-Hub sein. Import- und Exportfilter müssen die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zulassen, die von Backend-Instanzen oder Endpunkten verwendet werden.

  • Bei allen anderen Backend-Typen müssen sich alle Backends im selben VPC-Netzwerk und in derselben Region befinden.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an verschiedene NICs senden möchten, verwenden Sie stattdessen NEG-Backends.

Wenn Sie zonale NEG-Backends verwenden, werden Pakete an die Netzwerkschnittstelle gesendet, die durch den Endpunkt in der NEG dargestellt wird. Die NEG-Endpunkte müssen sich im selben VPC-Netzwerk wie das explizit definierte VPC-Netzwerk der NEG befinden.

Protokoll für die Kommunikation mit den Back-Ends

Wenn Sie einen Backend-Dienst für einen internen Proxy-Network Load Balancer konfigurieren, legen Sie das Protokoll fest, über das der Backend-Dienst mit den Backends kommuniziert. Der Load-Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln. Interne Proxy-Network Load Balancer unterstützen nur TCP für die Kommunikation mit den Backends.

Systemdiagnose

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.

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 TCP-Systemdiagnose die TCP-Konnektivität zu Back-Ends am genauesten testen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

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

Load-Balancer-Modus Systemdiagnosetyp
Regionaler interner Proxy-Network Load Balancer Regional regionHealthChecks
Regionsübergreifender interner Proxy-Network Load Balancer Global healthChecks

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für interne Proxy-Network Load Balancer sind die folgenden Firewallregeln erforderlich:

  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Systemdiagnoseprüfungen von Google zuzulassen.
    • 35.191.0.0/16
    • 130.211.0.0/22
    Bei IPv6-Traffic zu den Backends:
    • 2600:2d00:1:b029::/64
  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.

Die Ports für diese Firewallregeln müssen so konfiguriert werden:

  • Lassen Sie Traffic zum Zielport für die Systemdiagnose der einzelnen Backend-Dienste zu.

  • Instanzgruppen-Backends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Backend-Dienstes und den mit diesem benannten Port verknüpften Portnummern in jeder Instanzgruppe konfiguriert werden sollen. Die Portnummern können je nach Instanzgruppe, die demselben Backend-Dienst zugewiesen ist, variieren.

  • GCE_VM_IP_PORT-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

Für diese Load-Balancer gelten bestimmte Ausnahmen bei den Anforderungen an 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.

Bei 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 beliebigen Regionen auf Ihren Load Balancer zugreifen können.

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

In der folgenden Tabelle wird der Clientzugriff für regionale interne Proxy-Network 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.

Architektur einer freigegebenen VPC

Der interne Proxy-Network Load Balancer unterstützt Netzwerke, die eine freigegebene VPC verwenden. Mit einer freigegebenen VPC können Sie die Zuständigkeiten zwischen Netzwerkadministratoren und Dienstentwicklern klar trennen. Ihre Entwicklungsteams können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren und die Netzwerkinfrastrukturteams das Load-Balancing bereitstellen und verwalten. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

IP-Adresse Weiterleitungsregel Zielproxy Backend-Komponenten

Eine interne IP-Adresse muss im selben Projekt wie die Back-Ends definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne IP-Adresse von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-Ends definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.

 Der Zielproxy muss im selben Projekt wie die Back-Ends definiert werden. Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Backend-VMs normalerweise in einem Dienstprojekt. Dort müssen auch der regionale interne Backend-Dienst und die Systemdiagnose definiert werden.

Traffic-Verteilung

Ein interner Proxy-Network Load Balancer verteilt den Traffic so an seine Back-Ends:

  1. Verbindungen, die von einem einzelnen Client stammen, werden an dieselbe Zone gesendet, sofern fehlerfreie Back-Ends (Instanzgruppen oder NEGs) innerhalb dieser Zone verfügbar sind und Kapazität haben, wie durch den Balancing-Modus bestimmt. Bei regionalen internen Proxy-Network Load Balancern kann der Balancing-Modus CONNECTION (Instanz- oder NEG-Back-Ends) oder UTILIZATION (nur Instanzgruppen-Back-Ends) sein.
  2. Verbindungen von einem Client werden an dasselbe Backend gesendet, wenn Sie die Sitzungsaffinität konfiguriert haben.
  3. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß einer Load-Balancing-Richtlinie auf Instanzen (in einer Instanzgruppe) oder Endpunkte (in einer NEG) verteilt. Informationen zu den unterstützten Load-Balancing-Richtlinienalgorithmen finden Sie in der Einstellung localityLbPolicy in der API-Dokumentation für regionale Backend-Dienste.

Sitzungsaffinität

Mit der Sitzungsaffinität können Sie den Backend-Dienst des Load-Balancers so konfigurieren, dass alle Anfragen vom selben Client an dasselbe Backend gesendet werden, sofern das Backend fehlerfrei ist und Kapazität hat.

Der interne Proxy-Network Load Balancer bietet die Client-IP-Affinität, mit der alle Anfragen von derselben Client-IP-Adresse an dasselbe Backend weitergeleitet werden, sofern dieses Backend Kapazität hat und fehlerfrei ist.

Failover

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

In der folgenden Tabelle wird das Failover-Verhalten für interne Proxy-Network Load Balancer beschrieben:

Load-Balancer-Modus Failover-Verhalten Verhalten, wenn alle Back-Ends fehlerhaft sind
Regionaler interner Proxy-Network Load Balancer

Der Load-Balancer implementiert einen reibungslosen Failover-Algorithmus pro Zone. Anstatt zu warten, bis alle Back-Ends in einer Zone fehlerhaft werden, leitet der Load-Balancer den Traffic an eine andere Zone weiter, wenn das Verhältnis von fehlerfreien zu fehlerhaften Back-Ends in einer Zone unter einem bestimmten Prozentsatz liegt (70%, dieser Schwellenwert ist nicht konfigurierbar). Wenn alle Back-Ends in allen Zonen fehlerhaft sind, beendet der Load-Balancer die Clientverbindung sofort.

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

 Beendet die Verbindung
Regionsübergreifender interner Proxy-Network 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.

 Beendet die Verbindung

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in Google Kubernetes Engine erstellen, können Sie eigenständige zonale NEGs verwenden, um den Traffic direkt auf Container zu verteilen. Bei eigenständigen NEGs müssen Sie das Service-Objekt erstellen, das die zonale NEG erstellt, und dann die NEG mit dem Backend-Dienst verknüpfen, damit der Load-Balancer eine Verbindung zu den Pods herstellen kann.

Zugehörige GKE-Dokumentation:

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.

Beschränkungen

  • Der interne Proxy-Network Load Balancer unterstützt keinen IPv6-Traffic.
  • Der interne Proxy-Network Load Balancer unterstützt keine freigegebenen VPC-Bereitstellungen, bei denen sich das Frontend des Load Balancers in einem Host- oder Dienstprojekt befindet und der Backend-Dienst und die Backends in einem anderen Dienstprojekt sind (auch als projektübergreifende Dienstverweise bezeichnet).

Nächste Schritte