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:
Externer Application Load Balancer: Sorgt für das Load Balancing des Traffics, der von Clients aus dem Internet kommt. Weitere Informationen zur Architektur finden Sie unter Architektur des externen Application Load Balancers.
Bereitstellungsmodus Netzwerkdienststufe Load-Balancing-Schema IP-Adresse Frontend-Ports Global, extern Premium-Stufe EXTERNAL_MANAGED IPv4
IPv6Kann auf genau einen Port von 1–65535 verweisen.
Regional, extern Premium- oder Standardstufe EXTERNAL_MANAGED IPv4 Klassisch Global in Premium-Stufe
Regional in der Standardstufe.
EXTERN* IPv4
IPv6 (erfordert Premium-Stufe)*EXTERNAL_MANAGED-Back-End-Dienste können anEXTERNAL-Weiterleitungsregeln angehängt werden.EXTERNAL-Back-End-Dienste können jedoch nicht anEXTERNAL_MANAGED-Weiterleitungsregeln angehängt werden. Wenn Sie die neuen Funktionen nutzen möchten, die nur mit dem globalen externen Application Load Balancer verfügbar sind, empfehlen wir Ihnen, Ihre vorhandenenEXTERNAL-Ressourcen mithilfe des Migrationsvorgangs unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren zuEXTERNAL_MANAGEDzu migrieren.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. Weitere Informationen zur Architektur finden Sie unter Architektur des internen Application Load Balancers.
Bereitstellungsmodus Netzwerkdienststufe Load-Balancing-Schema IP-Adresse Frontend-Ports Regional intern Premium-Stufe INTERNAL_MANAGED IPv4 Kann auf genau einen Port von 1–65535 verweisen.
Regionenübergreifend, intern*
Premium-Stufe INTERNAL_MANAGED IPv4 * Der Load Balancer verwendet globale Ressourcen und kann in einer oder mehreren von Ihnen ausgewählten Google Cloud-Regionen bereitgestellt werden.
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-Envoy-Proxy implementiert wird. In einem Load Balancing-Schema, das _MANAGED ist, werden Anfragen entweder an das GFE oder an den Envoy-Proxy weitergeleitet.
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.
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.
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.
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 einer anderen Region befinden.
In diesem Beispiel für eine mehrstufige 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-west1ist, die auf die interne Datenbankebene mit Load-Balancing inus-east1zugreift.
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 Traffic-Verwaltung
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.
Hier finden Sie weitere Informationen:
- Trafficverwaltung für globale externe Application Load Balancer
- Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer
Erweiterbarkeit mit Diensterweiterungen
Durch die Einbindung von Diensterweiterungen können Sie benutzerdefinierte Logik in den Load Balancing-Pfad von unterstützten Application Load Balancern einfügen.
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.
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 globalen externen Application Load Balancern, klassischen Application Load Balancern und 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:
- 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 Run 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.
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.
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.
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.
Weitere Dokumentation:
- Übersicht über serverlose NEGs
- Globalen externen Application Load Balancer mit einem Cloud Run-, Cloud Run-Funktionen- oder App Engine-Backend einrichten
- Regionalen externen Application Load Balancer mit einem Cloud Run-Backend einrichten
- Regionalen internen Application Load Balancer mit einem Cloud Run-Backend einrichten
- Regionenübergreifenden internen Application Load Balancer mit Cloud Run einrichten
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 zugänglich sind, und dabei eine globale Internet-NEG verwendet wird.
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
Das regionenübergreifende Failover ist nur mit 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.
Weitere Informationen zur Funktionsweise des Failovers finden Sie in den folgenden Themen:
- Globale externe Application Load Balancer: Verteilung von Anfragen
- Regionenübergreifende interne Application Load Balancer: Hochverfügbarkeit und regionenübergreifender Failover