Application Load Balancer – Übersicht

Der Application Load Balancer ist ein proxybasierter Layer-7-Load Balancer, mit dem Sie Ihre Dienste ausführen und skalieren können. Der Application Load Balancer verteilt HTTP- und HTTPS-Traffic an Back-Ends, die auf verschiedenen Google Cloud-Plattformen gehostet werden, wie Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage und Cloud Run, sowie an externe Back-Ends, die über das Internet oder über eine Hybridkonnektivität verbunden sind.

Application Load Balancer sind in den folgenden Bereitstellungsmodi verfügbar:

	Bereitstellungsmodus	Netzwerkdienststufe	Load-Balancing-Schema ^†	IP-Adresse	Frontend-Ports	Links
Externer Application Load Balancer Sorgt für das Load-Balancing des Traffics, der von Clients aus dem Internet kommt.	Global, extern	Premium-Stufe	EXTERNAL_MANAGED	IPv4 IPv6	Kann auf genau einen Port von 1–65535 verweisen.	Architekturdetails
	Regional, extern	Premium- oder Standardstufe	EXTERNAL_MANAGED	IPv4
	Klassisch	Global in Premium-Stufe Regional in der Standardstufe.	EXTERN	IPv4 IPv6 erfordert Premium-Stufe
Interner Application Load Balancer Führt Load-Balancing von Traffic innerhalb Ihres VPC-Netzwerks oder der Netzwerke aus, die mit Ihrem VPC-Netzwerk verbunden sind.	Regional intern	Premium-Stufe	INTERNAL_MANAGED	IPv4	Kann auf genau einen Port von 1–65535 verweisen.	Architekturdetails
	Regionenübergreifend, intern^*	Premium-Stufe	INTERNAL_MANAGED	IPv4	Kann auf genau einen Port von 1–65535 verweisen.	Architekturdetails

^† Das Load-Balancing-Schema ist ein Attribut für die Weiterleitungsregel und den Backend-Dienst eines Load-Balancers und gibt an, ob der Load-Balancer für internen oder externen Traffic verwendet werden kann. Der Begriff *_MANAGED im Load-Balancing-Schema gibt an, dass der Load Balancer als verwalteter Dienst auf Google Front Ends (GFEs) oder dem Open-Source-Proxy Envoy implementiert wird. In einem Load-Balancing-Schema, das *_MANAGED ist, werden Anfragen entweder an das GFE oder an den Envoy-Proxy weitergeleitet.

^* Der Load-Balancer verwendet globale Ressourcen und kann in einer oder mehreren von Ihnen ausgewählten Google Cloud-Regionen bereitgestellt werden.

Externer Application Load Balancer

Externe Application Load Balancer werden mit Google Front Ends (GFEs) oder verwalteten Proxys implementiert. Globale externe Application Load Balancer und klassische Application Load Balancer verwenden GFEs, die weltweit verteilt sind und über das globale Netzwerk und die Steuerungsebene von Google zusammenarbeiten. GFEs bieten in der Premium-Stufe ein multiregionales Load-Balancing, das den Traffic an das nächstgelegene fehlerfreie Backend leitet, das über Kapazitäten verfügt, und den HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern beendet. Globale externe Application Load Balancers und regionale externe Application Load Balancers nutzen die Open-Source-Proxy-Software Envoy, um erweiterte Trafficverwaltungsfunktionen zu aktivieren.

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

Externe Application Load Balancer unterstützen die folgenden Funktionen:

Erweiterte Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung und Anfrage-/Antwort-basierte Headertransformationen. Weitere Informationen finden Sie unter Trafficverwaltung – Übersicht.
Load-Balancing von Traffic zu Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine, Kubernetes Engine (GKE) und Cloud Run gehostet werden. Die Backend-Unterstützung hängt vom Bereitstellungsmodus des Load Balancers ab. Informationen dazu finden Sie in der Übersicht über externen Application Load Balancer.
Im Cache gespeicherte Antworten mit Cloud CDN.
Schutz vor DDoS-Angriffen oder anderen Webangriffen durch Google Cloud Armor.
Load-Balancing zu GKE mit durch die Verwendung von Ingress oder Gateway (vollständig orchestriert) oder eigenständigen NEGs.
Regionale externe Application Load Balancer werden mit App Hub unterstützt, das sich in der Vorschau befindet.

Das folgende Diagramm zeigt eine Beispielarchitektur für einen externen Application Load Balancer.

Architektur des externen Application Load Balancers.

Eine vollständige Übersicht finden Sie unter Architekturübersicht für externe Application Load Balancer.

Interner Application Load Balancer

Die internen Application Load Balancer sind Envoy-Proxy-basierte regionale Layer-7-Load Balancer, mit denen Sie Ihren HTTP-Anwendungstraffic hinter einer internen IP-Adresse ausführen und skalieren können. Interne Application Load Balancer unterstützen Back-Ends in einer Region, können jedoch so konfiguriert werden, dass sie von Clients aus jeder Google Cloud-Region global zugänglich sind.

Der Load-Balancer verteilt Traffic an Back-Ends, die in Google Cloud, lokal oder in anderen Cloud-Umgebungen gehostet werden. Interne Application Load Balancer unterstützen auch die folgenden Features:

Ortsrichtlinien. Innerhalb einer Backend-Instanzgruppe oder Netzwerk-Endpunktgruppe können Sie konfigurieren, wie Anfragen an Mitgliedsinstanzen oder -Endpunkte verteilt werden. Weitere Informationen finden Sie unter Trafficverwaltung.
Globaler Zugriff. Wenn der globale Zugriff aktiviert ist, können Clients aus jeder Region auf den Load Balancer zugreifen. Weitere Informationen finden Sie unter Globalen Zugriff aktivieren.
Zugriff aus verbundenen Netzwerken. Sie können Ihren Load-Balancer für Clients aus Netzwerken über das eigene Google Cloud-VPC-Netzwerk (Virtual Private Cloud) zugänglich machen. Die anderen Netzwerke müssen über VPC-Netzwerk-Peering, Cloud VPN oder Cloud Interconnect mit dem VPC-Netzwerk des Load Balancers verbunden sein. Weitere Informationen finden Sie unter Zugriff auf verbundene Netzwerke.
Kompatibilität mit GKE mithilfe von Ingress (vollständig orchestriert). Weitere Informationen finden Sie unter Ingress für interne Application Load Balancer konfigurieren.
Regionale interne Application Load Balancer werden mit App Hub unterstützt, das sich in der Vorschau befindet.

Architektur des internen Application Load Balancers.

Eine vollständige Übersicht finden Sie unter Architekturübersicht für interne Application Load Balancer.

Anwendungsfälle

In den folgenden Abschnitten werden einige gängige Anwendungsfälle für Application Load Balancer beschrieben.

Dreistufige Webdienste

Sie können eine Kombination Application Load Balancern und Network Load Balancern bereitstellen, um konventionelle dreistufige Webdienste zu unterstützen. Das folgende Beispiel zeigt, wie Sie die einzelnen Ebenen je nach Traffictyp bereitstellen können:

Webstufe. Das Frontend der Anwendung wird von einem externen Application Load Balancer mit Instanzgruppen-Back-Ends bereitgestellt. Der Traffic geht aus dem Internet ein und wird vom Load Balancer an eine Reihe von Instanzgruppen-Back-Ends in verschiedenen Regionen weitergeleitet. Diese Back-Ends senden HTTP(S)-Traffic an eine Reihe von internen Application Load Balancern.
Anwendungsstufe. Die Middleware der Anwendung wird mithilfe eines internen Application Load Balancers und von Instanzgruppen-Back-Ends bereitgestellt und skaliert. Die Load Balancer verteilen den Traffic auf Middleware-Instanzgruppen. Diese Middleware-Instanzgruppen senden dann den Traffic an interne Passthrough-Network Load Balancer.
Datenbankstufe. Die Network Load Balancer dienen als Front-Ends für die Datenbankstufe. Sie verteilen den Traffic an Datenspeicher-Back-Ends in verschiedenen Regionen.

Auf Layer 7 basiertes Routing in einer dreistufigen Webanwendung.

Globaler Zugriff für regionale interne Application Load Balancer

Wenn Sie den globalen Zugriff für Ihren regionalen internen Application Load Balancer aktivieren, können sich Ihre Client-VMs auf Webebene in anderen Regionen befinden.

In diesem Beispiel für eine mehrschichtige Anwendung wird Folgendes gezeigt:

Eine global verfügbare Webebene im Internet, die den Traffic über einen externen Application Load Balancer verteilt.
Eine interne Backend-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.

Dreistufige Webanwendung mit einem externen Application Load Balancer, globalem Zugriff und einem internen Application Load Balancer. — Dreistufige Webanwendung mit externem Application Load Balancer, globaler Zugriff und einem internen Application Load Balancer (zum Vergrößern klicken)

Arbeitslasten mit gesetzlicher Compliance

Einige Arbeitslasten mit gesetzlichen oder Compliance-Anforderungen erfordern, dass sich Netzwerkkonfigurationen und Trafficbeendigung in einer bestimmten Region befinden. Für diese Arbeitslasten ist häufig ein regionaler externer Application Load Balancer die bevorzugte Option, um die von diesen Arbeitslasten benötigten gesetzlichen Kontrollen zu ermöglichen.

Erweiterte Trafficverwaltung

Die Application Load Balancer unterstützen erweiterte Features zur Trafficverwaltung, mit denen Sie genau steuern können, wie Ihr Traffic verarbeitet wird. Zu diesen Funktionen gehören:

Sie können die Verwaltung des Traffics aktualisieren, ohne den Anwendungscode ändern zu müssen.
Sie können Traffic anhand von HTTP(S)-Parametern wie Host, Pfad, Headern und anderen Anfrageparametern intelligent weiterleiten. Sie können beispielsweise Cloud Storage-Buckets für die Verarbeitung statischer Videoinhalte verwenden und Instanzgruppen oder NEGs für alle anderen Anfragen.
Sie können Risiken minimieren, wenn Sie eine neue Version Ihrer Anwendung bereitstellen. Verwenden Sie dazu die gewichtete Trafficaufteilung. Sie können beispielsweise 95 % des Traffics an die vorherige Version Ihres Dienstes und 5 % an die neue Version Ihres Dienstes senden. Nachdem Sie geprüft haben, ob die neue Version wie erwartet funktioniert, können Sie die Prozentsätze schrittweise ändern, bis 100 % des Traffics die neue Version Ihres Dienstes erreichen. Die Trafficaufteilung wird gewöhnlich zur Bereitstellung neuer Versionen, für A/B Testing, Dienstmigration, zur Modernisierung von Legacy-Diensten und für ähnliche Prozesse verwendet.

Im Folgenden finden Sie ein Beispiel für pfadbasiertes Routing, das mit einem internen Application Load Balancer implementiert wurde. Jeder Pfad wird von einem anderen Backend verarbeitet.

Pfadbasiertes Routing mit internen Application Load Balancern

Hier finden Sie weitere Informationen:

Erweiterbarkeit mit Diensterweiterungen

Mit Diensterweiterungs-Callouts können Sie benutzerdefinierte Logik in den Load Balancing-Datenpfad einfügen. Mit diesen Erweiterungen können Sie unterstützte Application Load Balancer anweisen, während der Datenverarbeitung gRPC-Aufrufe an nutzerverwaltete Anwendungen oder Dienste zu senden.

Weitere Informationen finden Sie unter Übersicht über Diensterweiterungen.

Legacy-Dienste zu Google Cloud migrieren

Durch die Migration eines vorhandenen Dienstes zu Google Cloud können Sie lokale Kapazität freigeben und die Kosten und den Aufwand für die Wartung einer lokalen Infrastruktur reduzieren. Sie können vorübergehend eine Hybridbereitstellung einrichten, die Ihnen die Weiterleitung von Traffic sowohl zu Ihrem derzeitigen lokalen Dienst als auch zu einem entsprechenden Endpunkt des Google Cloud-Dienstes ermöglicht.

Das folgende Diagramm veranschaulicht diese Einrichtung mit einem internen Application Load Balancer. Wenn Sie einen internen Load Balancer verwenden, können Sie den Load Balancer für Google Cloud so konfigurieren, dass die gewichtete Trafficaufteilung zum Aufteilen von Traffic auf die beiden Dienste verwendet wird. Bei der Trafficaufteilung können Sie mit dem Senden von 0 % des Traffics an den Google Cloud-Dienst und von 100 % an den lokalen Dienst beginnen. Anschließend können Sie den Anteil des an den Google Cloud-Dienst gesendeten Traffics schrittweise erhöhen. Schließlich senden Sie 100 % des Traffics an den Google Cloud-Dienst und deaktivieren den lokalen Dienst.

Legacy-Dienste zu Google Cloud migrieren.

Load-Balancing für GKE-Anwendungen

Es gibt drei Möglichkeiten, Application Load Balancer für GKE-Cluster bereitzustellen:

GKE Gateway Controller. Wird nur von den globalen externen Application Load Balancern, klassischen Application Load Balancern und den regionalen internen Application Load Balancern unterstützt. Eine Anleitung zur Einrichtung finden Sie unter Gateways bereitstellen.
GKE-Ingress-Controller: Sie können den integrierten GKE-Ingress-Controller verwenden, der Google Cloud-Load Balancer im Namen von GKE-Nutzern bereitstellt. Dies ist mit der eigenständigen Load-Balancing-Architektur identisch, mit dem Unterschied, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird. Unterstützt sowohl von externen als auch von internen Application Load Balancern. Eine Anleitung zur Einrichtung finden Sie hier:
- Ingress für externe Application Load Balancer konfigurieren
- Ingress für interne Application Load Balancer konfigurieren
Eigenständige zonale NEGs. Eigenständige NEGs werden über den GKE NEG-Controller bereitgestellt und verwaltet, aber alle Load-Balancing-Ressourcen (Weiterleitungsregeln, Systemdiagnosen usw.) werden manuell bereitgestellt. Diese werden sowohl von externen als auch von internen Application Load Balancern unterstützt.

Load-Balancing für Cloud Run-, Cloud Functions- und App Engine-Anwendungen

Sie können einen Application Load Balancer als Frontend für Ihre serverlosen Google Cloud-Anwendungen verwenden. Dadurch können Sie Ihre serverlosen Anwendungen so konfigurieren, dass Anfragen von einer dedizierten IP-Adresse verarbeitet werden, die nicht für andere Dienste freigegeben ist.

Für die Einrichtung verwenden Sie eine serverlose NEG für das Backend des Load Balancers. In den folgenden Diagrammen sehen Sie, wie eine serverlose Anwendung in einen Application Load Balancer eingebunden wird.

Global, extern

Dieses Diagramm zeigt, wie eine serverlose NEG in eine Architektur mit globalem externem Application Load Balancer passt.

Architektur des globalen externen Application Load Balancers für serverlose Anwendungen.

Regional, extern

Dieses Diagramm zeigt, wie eine serverlose NEG in eine Architektur mit regionalem externem Application Load Balancer passt. Dieser Load Balancer unterstützt nur Cloud Run-Back-Ends.

Architektur des regionalen externen Application Load Balancers für serverlose Anwendungen. — Architektur des regionalen externen Anwendungs-Load-Balancers für serverlose Anwendungen.

Regional intern

Dieses Diagramm zeigt, wie eine serverlose NEG in das Modell des regionalen internen Application Load Balancers passt. Dieser Load Balancer unterstützt nur Cloud Run-Back-Ends.

Architektur des regionalen internen Application Load Balancers für serverlose Anwendungen.

Regionenübergreifend, intern

Dieses Diagramm zeigt, wie eine serverlose NEG in das regionenübergreifende Aplication Load Balancer-Modell passt. Dieser Load Balancer unterstützt nur Cloud Run-Back-Ends.

Architektur des regionenübergreifenden internen Application Load Balancers für serverlose Anwendungen. — Architektur des regionenübergreifenden internen Application Load Balancers für serverlose Anwendungen (zum Vergrößern klicken).

Weitere Dokumentation:

Load-Balancing für Back-Ends außerhalb von Google Cloud

Application Load Balancer unterstützen Load-Balancing-Traffic zu Endpunkten, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere Cloud-Umgebungen. Auf externe Back-Ends kann in der Regel auf eine der folgenden Arten zugegriffen werden:

Über das öffentliche Internet zugänglich. Für diese Endpunkte verwenden Sie eine Internet-NEG als Backend des Load Balancers. Die Internet-NEG ist so konfiguriert, dass sie auf einen einzelnen FQDN:Port- oder IP:Port-Endpunkt auf dem externen Backend verweist. Internet-NEGs können global oder regional sein.

Das folgende Diagramm zeigt, wie eine Verbindung zu externen Back-Ends hergestellt wird, die über das öffentliche Internet mit einer globalen Internet-NEG zugänglich sind.

Globaler externer Application Load Balancer mit externem Backend.

Weitere Informationen finden Sie in der Übersicht über Internet-NEGs.
Zugriff über Hybridkonnektivität (Cloud Interconnect oder Cloud VPN) Für diese Endpunkte verwenden Sie eine Hybrid-NEG als Backend des Load Balancers. Die Hybrid-NEG ist so konfiguriert, dass sie auf IP:Port-Endpunkte im externen Backend verweist.

Die folgenden Diagramme zeigen, wie Sie eine Verbindung zu externen Back-Ends herstellen, auf die über Cloud Interconnect oder Cloud VPN zugegriffen werden kann.

Extern

Hybridkonnektivität mit globalen externen Application Load Balancern.

Intern

Hybridkonnektivität mit internen Application Load Balancern.

Weitere Informationen finden Sie unter Hybrid-NEGs – Übersicht.

Einbindung in Private Service Connect

Private Service Connect ermöglicht die private Nutzung von Diensten in VPC-Netzwerken, die zu verschiedenen Gruppen, Teams, Projekten oder Organisationen gehören. Mit Private Service Connect können Sie auf Google APIs und Google-Dienste oder verwaltete Dienste in einem anderen VPC-Netzwerk zugreifen.

Sie können einen globalen externen Application Load Balancer verwenden, um auf Dienste zuzugreifen, die mit Private Service Connect veröffentlicht wurden. Weitere Informationen finden Sie unter Private Service Connect-Back-Ends.

Sie können einen internen Application Load Balancer verwenden, um Anfragen an unterstützte regionale Google APIs und Dienste zu senden. Weitere Informationen finden Sie unter Über Google-APIs auf Back-Ends zugreifen.

Hochverfügbarkeit und regionsübergreifender Failover

Der regionenübergreifende Failover ist nur bei globalen externen Application Load Balancern, klassischen Application Load Balancern und regionenübergreifenden internen Application Load Balancern verfügbar. Mit diesen Load-Balancern können Sie die Dienstverfügbarkeit verbessern, wenn Sie globale Backend-Dienste mit Backends in mehreren Regionen erstellen. Wenn Back-Ends in einer bestimmten Region ausfallen, wird der Traffic problemlos auf eine andere Region umgeleitet.

Mehr zur Funktionsweise des Failovers finden Sie in den folgenden Themen: