Übersicht über Cloud Load Balancing

Ein Load-Balancer verteilt den Nutzertraffic auf mehrere Instanzen Ihrer Anwendungen. Durch die Verteilung der Last lässt sich mit Load-Balancing das Risiko verringern, dass Ihre Anwendungen Leistungsprobleme verursachen. Cloud Load Balancing von Google basiert auf zuverlässigen, leistungsstarken Technologien wie Maglev, Andromeda, Google Front Ends und Envoy – denselben Technologien, die auch für die eigenen Produkte von Google verwendet werden.

Cloud Load Balancing bietet ein umfassendes Portfolio an Anwendungs- und Netzwerk-Load-Balancern. Mit unseren globalen Proxy-Load-Balancern können Sie Millionen von Anfragen pro Sekunde zwischen Back-Ends in mehreren Regionen mit unserer Google Front End-Flotte an über 80 verschiedenen Standorten weltweit verteilen – alles mit einer einzigen Anycast-IP-Adresse. Mit unseren regionalen Proxy-Load-Balancern können Sie strenge rechtliche Kontrollen implementieren und Ihre Back-Ends und Proxys in einer Region Ihrer Wahl im Blick behalten, ohne sich um TLS/SSL-Auslagerungen kümmern zu müssen. Verwenden Sie unsere Passthrough-Load-Balancer, um mehrere Protokolle schnell an Back-Ends mit der hohen Leistung von Direct Server Return weiterzuleiten.

Wichtige Funktionen von Cloud Load Balancing

Cloud Load Balancing bietet die folgenden Load Balancing-Features:

• Einzelne Anycast-IP-Adresse. Mit Cloud Load Balancing ist eine einzige Anycast-IP-Adresse das Frontend für alle Ihre Backend-Instanzen in verschiedenen Regionen der Welt. Sie profitieren von einem regionenübergreifenden Load-Balancing, einschließlich automatischen Failovers auf mehrere Regionen. Dabei wird der Traffic zu Failover-Back-Ends verschoben, wenn Ihre primären Back-Ends fehlerhaft werden. Cloud Load Balancing reagiert sofort auf Änderungen hinsichtlich Nutzern, Traffic, Netzwerk, Backend-Zustand und anderen damit verbundenen Bedingungen.

• Nahtloses Autoscaling. Mit Cloud Load Balancing wird einfach dem Nutzer- und Trafficaufkommen entsprechend skaliert. Dies gilt auch für die Verarbeitung unerwarteter und plötzlich auftretender starker Spitzen. Der Traffic wird dabei weltweit auf andere Regionen mit verfügbaren Kapazitäten umgeleitet. Autoscaling erfordert keine Vorbereitung. Sie können innerhalb von Sekunden von null auf vollen Traffic skalieren.

• Softwarebasiertes Load-Balancing. Cloud Load Balancing ist ein vollständig verteilter, softwarebasierter verwalteter Dienst für Ihren gesamten Traffic. Da Cloud Load Balancing nicht auf Instanzen oder Geräten beruht, sind Sie an keine physische Load-Balancing-Infrastruktur gebunden. Auch die Herausforderungen hinsichtlich Hochverfügbarkeit, Skalierung und Verwaltung, wie sie bei instanzbasierten Load-Balancern auftreten, entfallen.

• Layer-4- und Layer-7-Load-Balancing. Verwenden Sie das Layer-4-basierte Load-Balancing, um Traffic anhand von Daten aus Netzwerk- und Transportschichtprotokollen wie TCP, UDP, ESP, GRE, ICMP und ICMPv6 weiterzuleiten. Verwenden Sie Layer-7-basiertes Load-Balancing zum Hinzufügen von Entscheidungen über das Anfragerouting basierend auf Attributen wie HTTP-Header und Uniform Resource Identifier.

• Externes und internes Load-Balancing Gibt an, ob der Load-Balancer für externen oder internen Zugriff verwendet werden kann. Sie können einen externen Load Balancer verwenden, wenn Ihre Clients über das Internet auf Ihre Anwendung zugreifen müssen. Sie können einen internen Load-Balancer verwenden, wenn sich Ihre Clients inGoogle Cloudbefinden. Weitere Informationen finden Sie unter Externes und internes Load-Balancing.

• Globales und regionales Load-Balancing Definiert den Bereich des Load-Balancers. Ein globaler Load-Balancer unterstützt Back-Ends in mehreren Regionen, während ein regionaler Load-Balancer Back-Ends in einer einzelnen Region unterstützt. Obwohl sich die IP-Adresse eines regionalen Load-Balancers in einer Region befindet, ist ein regionaler Load-Balancer global zugänglich. Sie können Ihre Back-Ends auf eine oder mehrere Regionen verteilen, um Verbindungen in der Nähe Ihrer Nutzer zu beenden und Ihre Anforderungen an die Hochverfügbarkeit zu erfüllen. Weitere Informationen finden Sie unter Globales oder regionales Load-Balancing.

• Traffic-Routing in der Premium-Stufe- und der Standardstufe: Die Load-Balancing-Dienste in Google Cloud sind je nach der von Ihnen gewählten Netzwerkstufe (Premium-Stufe- oder Standardstufe) unterschiedlich. Die Premiumstufe ist teurer als die Standardstufe. Bei der Premium-Stufe wird das globale Hochleistungs-Backbone von Google verwendet, während bei der Standardstufe das öffentliche Internet zum Weiterleiten von Traffic im Netzwerk genutzt wird. Die von Ihnen gewählte Netzwerkdienststufe hängt davon ab, ob Sie Kosten oder Leistung für Ihre Unternehmensarbeitslast priorisieren. Einige Load-Balancing-Dienste sind nur in der Premium-Stufe und nicht in der Standardstufe verfügbar. Weitere Informationen finden Sie unter Premium- oder Standard-Netzwerkdienststufe.

• Unterstützung erweiterter Features. Cloud Load Balancing unterstützt Features wie das IPv6-Load-Balancing, Quell-IP-basierte Traffic-Steuerung, gewichtetes Load-Balancing, WebSockets, benutzerdefinierte Anfrage-Header und Protokollweiterleitung für private virtuelle IP-Adressen (VIPs).

  Es enthält auch die folgenden Integrationen:

  • Integration in Cloud CDN für die Inhaltsübermittlung aus dem Cache. Cloud CDN wird mit dem globalen externen Application Load Balancer und dem klassischen Application Load Balancer unterstützt.
  • Integration in Google Cloud Armor zum Schutz Ihrer Infrastruktur vor DDoS-Angriffen (Distributed Denial of Service) und anderen gezielten Anwendungsangriffen. Immer aktiver On-DDoS-Schutz ist für den globalen externen Application Load Balancer, den klassischen Application Load Balancer, den externen Proxy-Network-Load-Balancer und den externen Passthrough-Network-Load-Balancer verfügbar. Darüber hinaus unterstützt Google Cloud Armor den erweiterten DDoS-Netzwerkschutz nur für externe Passthrough-Network-Load-Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.

Arten von Google Cloud Load-Balancern

Cloud Load Balancing bietet zwei Arten von Load-Balancern: Application Load Balancer und Network Load Balancer. Wählen Sie einen Application Load Balancer aus, wenn Sie einen Layer-7-Load-Balancer für Ihre Anwendungen mit HTTP(S)-Traffic benötigen. Wählen Sie einen Network Load Balancer aus, wenn Sie einen Layer-4-Load-Balancer benötigen, der TLS-Auslagerung (mit einem Proxy-Load-Balancer) unterstützt, oder wenn Sie Unterstützung für IP-Protokolle wie UDP, ESP und ICMP (mit einem Passthrough-Load-Balancer) benötigen.

In der folgenden Tabelle finden Sie einen allgemeinen Überblick über die verschiedenen Arten vonGoogle Cloud -Load-Balancern, kategorisiert nach der OSI-Schicht, auf der sie ausgeführt werden, und danach, ob sie für externen oder internen Zugriff verwendet werden.

lan Cloud Load Balancing	Extern (Akzeptiert Internet-Traffic)	Intern (Akzeptiert internen Google Cloud Traffic)
Application Load Balancer HTTPS Layer-7-Load-Balancing	global extern regional extern klassisch	Regionenübergreifend, intern regional intern
Network Load Balancer TCP/SSL/Other Layer-4-Load-Balancing
	Proxy-Network-Load-Balancer
	global extern regional extern klassisch	Regionenübergreifend, intern regional intern
	Passthrough-Network-Load-Balancer
	regional extern	regional intern

Application Load Balancer

Application Load Balancer sind proxybasierte Layer-7-Load-Balancer, mit denen Sie Ihre Services hinter einer Anycast-IP-Adresse ausführen und skalieren können. Der Application Load Balancer verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die auf einer Vielzahl von Google Cloud Plattformen wie Compute Engine und Google Kubernetes Engine (GKE) gehostet werden, sowie auf externe Back-Ends außerhalb vonGoogle Cloud.

Das folgende Diagramm bietet einen allgemeinen Überblick über die verschiedenen Arten von Application Load Balancern, die extern oder intern bereitgestellt werden können, je nachdem, ob Ihre Anwendung mit dem Internet oder intern verbunden ist.

Externe Application Load Balancer sind als verwaltete Dienste implementiert, entweder auf Google Front Ends (GFEs) oder auf Envoy-Proxys. Clients können von überall im Internet aus eine Verbindung zu diesen Load Balancern herstellen. Bitte beachten Sie dabei Folgendes:

• Diese Load Balancer können in den folgenden Modi bereitgestellt werden: global, regional oder klassisch.
• Globale externe Application Load Balancer unterstützen Backends in mehreren Regionen.
• Regionale externe Application Load Balancer unterstützen nur Backends in einer einzelnen Region.
• Klassische Application Load Balancer sind in der Premium-Stufe global. In der Standardstufe können sie Traffic nur an Back-Ends in einer einzelnen Region verteilen.
• Application Load Balancer verwenden den Open-Source-Envoy-Proxy, um erweiterte Funktionen zur Trafficverwaltung zu aktivieren.

Interne Application Load Balancer basieren auf dem Andromeda-Stack zur Netzwerkvirtualisierung und dem Open-Source-Envoy-Proxy. Dieser Load-Balancer bietet internes Proxy-basiertes Load-Balancing für Layer-7-Anwendungsdaten. Der Load Balancer verwendet eine interne IP-Adresse, auf die nur Clients im selben VPC-Netzwerk oder Clients, die mit Ihrem VPC-Netzwerk verbunden sind, zugreifen können. Wichtige Hinweise:

• Diese Load Balancer können in den folgenden Modi bereitgestellt werden: regional oder regionenübergreifend.
• Regionale interne Application Load Balancer unterstützen nur Back-Ends in einer einzelnen Region.
• Regionenübergreifende interne Application Load Balancer (Vorschau) unterstützen Backends in mehreren Regionen und sind immer global zugänglich. Clients aus jederGoogle Cloud -Region können Traffic an den Load Balancer senden.

Weitere Informationen zu Application Load Balancern finden Sie unter Application Load Balancer.

Network Load Balancer

Network Load Balancer sind Layer-4-Load-Balancer, die TCP-, UDP- oder anderen IP-Protokoll-Traffic verarbeiten können. Diese Load-Balancer sind entweder als Proxy-Load-Balancer oder als Passthrough-Load-Balancer verfügbar. Sie können einen Load-Balancer abhängig von den Anforderungen Ihrer Anwendung und der Art des zu verarbeitenden Traffics auswählen. Wählen Sie einen Proxy-Network-Load-Balancer aus, wenn Sie einen Reverse-Proxy-Load-Balancer mit Unterstützung für erweiterte Trafficsteuerungen und Back-Ends lokal und in anderen Cloud-Umgebungen konfigurieren möchten. Wählen Sie einen Passthrough-Network Load Balancer aus, wenn Sie die Quell-IP-Adresse der Clientpakete beibehalten möchten, die direkte Serverrückgabe für Antworten bevorzugen oder eine Vielzahl von IP-Protokollen wie TCP, UDP, ESP, GRE, ICMP und ICMPv6 verarbeiten möchten.

Proxy-Network-Load-Balancer

Proxy-Network-Load-Balancer sind Layer-4-Reverse-Proxy-Load-Balancer, die TCP-Traffic auf VM-Instanzen (virtuelle Maschine) in Ihrem Google Cloud-VPC-Netzwerk verteilen. Der Traffic wird auf der Load Balancing-Ebene beendet und dann über TCP an das nächstgelegene verfügbare Backend weitergeleitet.

Das folgende Diagramm bietet einen allgemeinen Überblick über die verschiedenen Arten von Proxy-Network-Load-Balancern, die extern oder intern bereitgestellt werden können, je nachdem, ob Ihre Anwendung mit dem Internet oder intern verbunden ist.

Externe Proxy-Network-Load-Balancer sind Layer-4-Load-Balancer, die Traffic aus dem Internet auf Back-Ends in Ihrem Google Cloud VPC-Netzwerk, lokal oder in anderen Cloud-Umgebungen verteilen. Diese Load Balancer basieren entweder auf Google Front Ends (GFEs) oder auf Envoy-Proxys.

Diese Load Balancer können in den folgenden Modi bereitgestellt werden: global, regional oder klassisch.

• Globale externe Proxy-Network-Load-Balancer unterstützen Back-Ends in mehreren Regionen.
• Regionale externe Proxy-Network-Load-Balancer unterstützen Back-Ends in einer einzelnen Region.
• Klassische Proxy-Network Load Balancer sind in der Premium-Stufe global. In der Standardstufe können sie Traffic nur an Back-Ends in einer einzelnen Region verteilen.

Interne Proxy-Network-Load-Balancer sind Envoy-Proxy-basierte regionale Layer-4-Load-Balancer, mit denen Sie Ihren TCP-Diensttraffic hinter einer internen IP-Adresse, auf die nur Clients im selben VPC-Netzwerk oder Clients, die mit Ihrem VPC-Netzwerk verbunden sind, Zugriff haben, ausführen und skalieren können.

Diese Load Balancer können in einem der folgenden Modi bereitgestellt werden: regional oder regionenübergreifend.

• Regionale interne Proxy-Network-Load-Balancer unterstützen nur Back-Ends in einer einzelnen Region.
• Regionenübergreifende interne Proxy-Network Load Balancer (Vorschau) unterstützen Back-Ends in mehreren Regionen und sind immer global zugänglich. Clients aus jederGoogle Cloud -Region können Traffic an den Load Balancer senden.

Weitere Informationen zu Proxy-Network Load Balancern finden Sie unter Übersicht über Proxy-Network Load Balancer.

Passthrough-Network-Load-Balancer

Passthrough-Network-Load-Balancer sind regionale Layer-4-Passthrough-Load-Balancer. Diese Load-Balancer verteilen den Traffic zwischen Back-Ends in derselben Region wie der Load-Balancer. Sie werden mithilfe eines virtuellen Andromeda-Netzwerks und Google Maglev implementiert.

Wie der Name verrät, sind diese Load Balancer keine Proxys. Pakete mit Load-Balancing werden von Backend-VMs mit den Quell- und Ziel-IP-Adressen des Pakets, dem Protokoll und den unveränderten Quell- und Zielports angezeigt, wenn das Protokoll portbasiert ist. Verbindungen mit Load Balancing werden bei den Backends beendet. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe (DSR).

Diese Load Balancer werden, wie im folgenden Bild dargestellt, in zwei Modi bereitgestellt, je nachdem, ob der Load Balancer mit dem Internet oder intern verbunden ist.

• Externe Passthrough-Network-Load-Balancer basieren auf Maglev. Clients können unabhängig von ihren Netzwerkdienststufen von überall im Internet aus eine Verbindung zu diesen Load Balancern herstellen. Der Load-Balancer kann auch Traffic von Google Cloud VMs mit externen IP-Adressen oder von Google Cloud VMs empfangen, die über Cloud NAT oder instanzbasiertes NAT Internetzugriff haben.

  Backends für externe Passthrough-Network Load Balancer können entweder mit einem Backend-Dienst oder mit einem Zielpool bereitgestellt werden. Für neue Bereitstellungen empfehlen wir die Verwendung von Backend-Diensten.

• Interne Passthrough-Network-Load-Balancer basieren auf dem Andromeda-Stack zur Netzwerkvirtualisierung. Mit einem internen Passthrough-Network-Load-Balancer können Sie TCP/UDP-Traffic hinter einer internen Load-Balancing-IP-Adresse, die nur für Systeme im selben VPC-Netzwerk oder für Systeme, die mit Ihrem VPC-Netzwerk verbunden sind, gleichmäßig verteilen. Außerdem kann dieser Load-Balancer nur in der Premiumstufe konfiguriert werden.

Weitere Informationen zu Passthrough-Network Load Balancern finden Sie unter Passthrough-Network Load Balancer.

Komponenten des Lastenausgleichsmoduls

Ein Load-Balancer ist ein System, das aus mehreren interagierenden Komponenten besteht. Es gibt keine einzelne API-Ressource, die einen Load-Balancer darstellt. Stattdessen arbeiten mehrere Komponenten zusammen, um den eingehenden Traffic auf mehrere Back-Ends zu verteilen.

Das folgende Diagramm zeigt die Kernkomponenten eines Application Load Balancers, eines Proxy-Network-Load-Balancers und eines Passthrough-Network-Load-Balancers.

Die folgenden Informationen bieten einen allgemeinen Überblick über die wichtigsten Komponenten eines Load-Balancers, beginnend mit dem Punkt, an dem Traffic den Load-Balancer erreicht, bis hin zur Weiterleitung an die Backend-Ressource. Weitere Informationen zu den einzelnen Load-Balancer-Komponenten finden Sie auf der Seite, die in den einzelnen Abschnitten verlinkt ist.

Weiterleitungsregel

Eine Weiterleitungsregel gibt eine IP-Adresse, ein IP-Protokoll und einen oder mehrere Ports an, an denen der Load Balancer Traffic annimmt. Die Weiterleitungsregel und die zugehörige IP-Adresse bilden das Frontend eines Google Cloud Load-Balancers.

Weitere Informationen finden Sie unter Weiterleitungsregeln – Übersicht.

Zielproxy

Zielproxys beenden eingehende Verbindungen von Clients und erstellen neue Verbindungen vom Load Balancer zu den Back-Ends.

• Die erste Verbindung stammt vom Client und wird am Zielproxy des Load Balancers beendet.

• Die zweite Verbindung beginnt am Zielproxy und endet an der Backend-Instanz, die die Clientanfrage verarbeitet.

Die erste Verbindung wird entweder in einem Google Front End (GFE) oder in einem speziell dafür vorgesehenen Subnetz beendet, das als Nur-Proxy-Subnetz bezeichnet wird und ausschließlich für Envoy-Proxys reserviert ist. Ob ein Load-Balancer auf GFE oder Envoy basiert, können Sie der Tabelle im Abschnitt Zugrunde liegende Technologien von Google Cloud Load-Balancern in diesem Dokument entnehmen.

Zielproxys werden nur von proxybasierten Load Balancern wie Application Load Balancern und Proxy-Network Load Balancern verwendet. Bei diesen Arten von Load-Balancern werden Antworten von den Backend-Instanzen an den Zielproxy und nicht direkt an den Client zurückgesendet.

Weitere Informationen finden Sie unter Zielproxys.

Nur-Proxy-Subnetz

Ein Nur-Proxy-Subnetz bietet einen Pool von IP-Adressen, die ausschließlich für Envoy-Proxys reserviert sind, die von Google Cloud Load-Balancern verwendet werden. Die Proxys beenden eingehende Verbindungen und stellen dann neue Verbindungen zum Backend her.

Weitere Informationen finden Sie unter Nur-Proxy-Subnetze für Envoy-basierte Load Balancer.

SSL-Zertifikate

SSL-Zertifikate, auch bekannt als Transport Layer Security (TLS)-Zertifikate, ermöglichen eine sichere Kommunikation zwischen Clients und Load-Balancern. Proxybasierte Load Balancer, deren Weiterleitungsregeln auf einen Ziel-HTTPS-Proxy oder einen Ziel-SSL-Proxy verweisen, benötigen einen privaten Schlüssel und ein SSL-Zertifikat als Teil der Zielproxy-Konfiguration des Load Balancers.

Weitere Informationen finden Sie unter SSL-Zertifikate.

URL-Zuordnung

Nachdem die Verbindung beendet wurde, verwendet der HTTP(S)-Zielproxy die URL-Zuordnung, um zu entscheiden, wohin die neue Anfrage (die zweite Verbindung, wie im Abschnitt Zielproxy beschrieben) weitergeleitet werden soll. Die Anfrage wird entweder an den Back-End-Dienst oder an den Back-End-Bucket weitergeleitet. URL-Zuordnungen werden nur von Application Load Balancern verwendet. Da Application Load Balancer auf Layer 7 des OSI-Modells ausgeführt werden, können sie Routingentscheidungen auf Grundlage von HTTP-Attributen wie Domainname, Anfragepfad und Abfrageparametern treffen.

Weitere Informationen finden Sie unter URL-Zuordnungen.

Backend-Dienst

Ein Back-End-Dienst definiert, wie Ihr Load Balancer Traffic verteilt. Die Konfiguration des Back-End-Dienstes enthält eine Reihe von Werten, z. B. das Protokoll, das für die Verbindung zu Back-Ends verwendet wird, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen.

Mit diesen Einstellungen können Sie das Verhalten Ihres Load-Balancers genau steuern und Traffic an die richtigen Back-Ends weiterleiten. Das können entweder VM-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sein.

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

Backend-Bucket

Wenn Ihre Arbeitslast statische Inhalte über das HTTP(S)-Protokoll bereitstellt, können Sie einen Cloud Storage-Bucket zum Speichern statischer Inhalte und dann einen Back-End-Bucket zum Weiterleiten von Anfragen verwenden.

Systemdiagnosen

Wenn Sie den Backend-Dienst eines Load-Balancers konfigurieren, müssen Sie eine oder mehrere Systemdiagnosen für die zugehörigen Backends angeben. Wie der Name schon sagt, wird mit einer Systemdiagnose ermittelt, ob die Back-End-Instanzen des Load-Balancers fehlerfrei sind. Diese Entscheidung basiert auf der Fähigkeit des Back-Ends, auf eingehenden Traffic zu reagieren. Der Traffic, auf den ein Back-End reagieren muss, hängt vom Typ des Load-Balancers ab. Sie können Systemdiagnosen mit Layer 7- und Layer 4-Protokollen erstellen, um Instanzen mit Load-Balancing zu überwachen.

Firewallregeln

Damit Systemdiagnosen funktionieren, müssen Sie allow-Firewallregeln für eingehenden Traffic erstellen, die es Systemdiagnoseprüfungen ermöglichen, Ihre Back-Ends zu erreichen.

Load-Balancer, die auf Google Front Ends basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic von den CIDRs von Google Front End zu Ihren Back-Ends zulässt. Load-Balancer, die auf dem Open-Source-Envoy-Proxy basieren, erfordern eine allow-Firewallregel für eingehenden Traffic, die Traffic vom Nur-Proxy-Subnetz zu den Backend-Instanzen zulässt.

Weitere Informationen finden Sie unter Firewallregeln.

Back-Ends

Back-Ends sind das endgültige Ziel von Load-Balancing-Traffic.

Verschiedene Load Balancer unterstützen unterschiedliche Arten von Back-Ends. Wenn Sie dem Back-End-Dienst ein Back-End hinzufügen, geben Sie einen Balancing-Modus an, der die Kapazität des Back-Ends zur Verarbeitung neuer Anfragen bewertet und bestimmt, wie der Traffic auf die Back-Ends verteilt wird.

Weitere Informationen finden Sie unter Back-Ends.

Zugrunde liegende Technologien von Google Cloud Load-Balancern

In der folgenden Tabelle ist die zugrunde liegende Technologie aufgeführt, auf der jederGoogle Cloud Load-Balancer basiert.

• Google Front Ends (GFEs) sind softwarebasierte, verteilte Systeme, die sich in Google-PoPs (Points of Presence) befinden und globales Load-Balancing in Verbindung mit anderen Systemen und Steuerungsebenen ausführen.
• Andromeda ist der softwarebasierte Netzwerkvirtualisierungs-Stack von Google Cloud.
• Maglev ist ein verteiltes System für das Netzwerk-Load-Balancing.
• Envoy ist ein Open-Source-Edge- und ‑Dienstproxy, der für cloudnative Anwendungen entwickelt wurde.

Load-Balancer	Technologie
Globaler externer Application Load Balancer	Envoy-basiertes Google Front End (GFE)
Klassischer Application Load Balancer	GFE
Regionaler externer Application Load Balancer	Envoy
Regionsübergreifender interner Application Load Balancer	Envoy
Regionaler interner Application Load Balancer	Envoy
Globaler externer Proxy-Network Load Balancer	Envoy-basierte GFE
Klassischer Proxy-Network Load Balancer	GFE
Regionaler externer Proxy-Network Load Balancer	Envoy
Regionaler interner Proxy-Network Load Balancer	Envoy
Regionsübergreifender interner Proxy-Network Load Balancer	Envoy
Externer Passthrough-Network Load Balancer	Maglev
Interner Passthrough-Network Load Balancer	Andromeda

Load-Balancer auswählen

Um zu bestimmen, welches Cloud Load Balancing-Produkt verwendet werden soll, müssen Sie erst einmal festlegen, welche Art von Traffic Ihre Load-Balancer verarbeiten müssen. In der Regel wählen Sie einen Application Load Balancer aus, wenn Sie ein flexibles Feature-Set für Ihre Anwendungen mit HTTP(S)-Traffic benötigen. Außerdem verwenden Sie einen Network Load Balancer, wenn Sie eine umfangreiche TLS-Auslagerung oder Unterstützung für UDP benötigen oder Client-IP-Adressen für Ihre Anwendungen freigeben müssen.

Sie können Ihre Auswahl weiter eingrenzen, abhängig von den Anforderungen Ihrer Anwendung: Ob Ihre Anwendung extern (mit dem Internet) oder intern verbunden ist, ob Sie global oder regional bereitgestellte Back-Ends benötigen und ob Sie Premium oder Standard-Netzwerkdienststufe benötigen.

Das folgende Diagramm zeigt alle verfügbaren Bereitstellungsmodi für Cloud Load Balancing. Weitere Informationen finden Sie im Leitfaden zum Auswählen eines Load-Balancers.

Zusammenfassung der Typen von Google Cloud Load-Balancern

Die folgende Tabelle enthält Details wie die Netzwerkdienststufe, auf der jeder Load Balancer ausgeführt wird, sowie das zugehörige Load-Balancing-Schema.

Load-Balancer	Bereitstellungsmodus	Traffictyp	Netzwerkdienststufe	Load-Balancing-Schema1
Application Load Balancer	Global, extern	HTTP oder HTTPS	Premium-Stufe	EXTERNAL_MANAGED
	Regional, extern	HTTP oder HTTPS	Premium- oder Standardstufe	EXTERNAL_MANAGED
	Klassisch	HTTP oder HTTPS	Global in der Premium-Stufe Regional in der Standardstufe.	EXTERN2
	Regional intern3	HTTP oder HTTPS	Premium-Stufe	INTERNAL_MANAGED
	Regionenübergreifend, intern	HTTP oder HTTPS	Premium-Stufe	INTERNAL_MANAGED
Proxy-Network-Load-Balancer	Global, extern	TCP mit optionaler SSL-Auslagerung	Premium-Stufe	EXTERNAL_MANAGED
	Regional, extern	TCP	Premium- oder Standardstufe	EXTERNAL_MANAGED
	Klassisch	TCP mit optionaler SSL-Auslagerung	Global in der Premium-Stufe Regional in der Standardstufe.	EXTERN
	Regional intern3	TCP ohne SSL-Übertragung	Premium-Stufe	INTERNAL_MANAGED
	Regionenübergreifend, intern	TCP ohne SSL-Übertragung	Premium-Stufe	INTERNAL_MANAGED
Passthrough-Network-Load-Balancer	Extern Immer regional	TCP, UDP, ESP, GRE, ICMP und ICMPv6	Premium- oder Standardstufe	EXTERN
	Intern3 Immer regional	TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE	Premium-Stufe	INTERN

Schnittstellen

Sie können Ihre Load-Balancer über folgende Oberflächen konfigurieren und aktualisieren:

• Die Google Cloud-CLI: Ein Befehlszeilentool, das in der Google Cloud-CLI enthalten ist. In der Dokumentation wird dieses Tool häufig zum Ausführen von Aufgaben erwähnt. Eine vollständige Übersicht über das Tool finden Sie im Leitfaden zur gcloud CLI. Befehle im Zusammenhang mit dem Load-Balancing finden Sie in der Befehlsgruppe gcloud compute.

  Ausführliche Hilfe zu jedem gcloud-Befehl erhalten Sie auch mit dem Flag --help:

  gcloud compute http-health-checks create --help
  
  

• Die Google Cloud Console: Load-Balancing-Aufgaben können über die Google Cloud Console ausgeführt werden.

• Die REST API: Alle Load-Balancing-Aufgaben können mit der Cloud Load Balancing API ausgeführt werden. In der API-Referenzdokumentation werden die verfügbaren Ressourcen und Methoden beschrieben.

• Terraform: Sie können ein Open-Source-Infrastruktur-als-Code-Tool wie Terraform verwenden, um die Google Cloud-Load-Balancing-Infrastruktur bereitzustellen, zu aktualisieren und zu löschen.

Nächste Schritte

• Informationen darüber, welcher Google Cloud Load-Balancer Ihren Anforderungen am besten entspricht, finden Sie unter Load-Balancer auswählen.
• Eine vergleichende Übersicht über die von Cloud Load Balancing angebotenen Load-Balancing-Features finden Sie unter Load-Balancer-Features im Vergleich.