Übersicht über externen Application Load Balancer

In diesem Dokument werden die grundlegenden Konzepte zum Konfigurieren eines externen Application Load Balancers vorgestellt.

Ein externer Application Load Balancer ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Der externe Application Load Balancer verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die auf einer Vielzahl vonGoogle Cloud -Plattformen wie Compute Engine, Google Kubernetes Engine (GKE) und Cloud Storage gehostet werden, sowie auf externe Back-Ends, die über das Internet oder Hybridkonnektivität verbunden sind. Weitere Informationen finden Sie unter Application Load Balancer: Anwendungsfälle.

Betriebsarten

Sie können einen externen Application Load Balancer in den folgenden Modi konfigurieren:

  • Globale externe Application Load Balancer. Dies ist ein globaler Load-Balancer, der als verwalteter Dienst auf Google Front Ends (GFEs) implementiert ist. Der Open-Source-Envoy-Proxy unterstützt erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung und anfrage- oder antwortbasierte Header-Transformationen.
  • Klassische Application Load Balancer. Dies ist der klassische externe Application Load Balancer, der in der Premium-Stufe global ist, aber als regionale Standardstufe konfiguriert werden kann. Dieser Load-Balancer ist auf Google Front Ends (GFEs) implementiert. GFEs sind global verteilt und arbeiten über das globale Netzwerk und die Steuerungsebene von Google zusammen.
  • Regionaler externer Application Load Balancer Dies ist ein regionaler Load-Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung und anfrage- oder antwortbasierte Headertransformationen.
Load-Balancer-Modus Empfohlene Anwendungsfälle Leistungsspektrum
Globaler externer Application Load Balancer Verwenden Sie diesen Load-Balancer für externe HTTP(S)-Arbeitslasten mit global verteilten Nutzern oder Backend-Diensten in mehreren Regionen.
Klassischer Application Load Balancer

Dieser Load Balancer ist in der Premium-Stufe global. In der Premium-Netzwerkdienststufe bietet dieser Load-Balancer multiregionales Load-Balancing, versucht, Traffic an das nächstgelegene fehlerfreie Backend mit Kapazität weiterzuleiten, und beendet HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern. Weitere Informationen zum Prozess der Anfrageverteilung finden Sie unter Trafficverteilung.

In der Standard-Netzwerkdienststufe kann dieser Load Balancer Traffic nur an Back-Ends in einer einzelnen Region verteilen.
  • Kompatibel mit GKE mithilfe von Gateway (vollständig orchestriert), Ingress (vollständig orchestriert) oder eigenständigen NEGs (manuelle Orchestrierung).
  • Unterstützt Google Cloud Armor
  • Weniger Traffic-Routing-Features
Eine vollständige Liste der Funktionen finden Sie auf der Seite Load-Balancing-Features.
Regionaler externer Application Load Balancer

Dieser Load Balancer enthält viele Features des bestehenden klassischen Application Load Balancers sowie erweiterte Funktionen für die Trafficverwaltung.

Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen.

Dieser Load Balancer kann entweder in der Premium- oder der Standardstufe konfiguriert werden.

 Eine vollständige Liste finden Sie unter Load-Balancing-Features.

Modus bestimmen

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, ist der Load-Balancer global. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

Load-Balancer-Modus Load Balancer-Typ Zugriffstyp Region
Globaler externer Application Load Balancer Anwendung Extern
Klassischer Application Load Balancer Anwendung (klassisch) Extern
Regionaler externer Application Load Balancer Anwendung Extern Gibt eine Region an

gcloud

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 Netzwerkstufe
Globaler externer Application Load Balancer EXTERNAL_MANAGED Global Premium
Klassischer Application Load Balancer EXTERN Global Standard oder Premium
Regionaler externer Application Load Balancer EXTERNAL_MANAGED Gibt eine Region an Standard oder Premium

Architektur

Die folgenden Ressourcen sind für die Bereitstellung eines externen Application Load Balancers erforderlich:

  • Bei regionalen externen Application Load Balancern ausschließlich wird ein Nur-Proxy-Subnetz verwendet, um Verbindungen vom Load-Balancer zu den Back-Ends zu senden.

  • Eine externe Weiterleitungsregel gibt eine externe IP-Adresse, einen Port und einen HTTP(S)-Ziel-Proxy an. Clients verwenden die IP-Adresse und den Port, um eine Verbindung zum Load-Balancer herzustellen.

  • Ein HTTP(S)-Ziel-Proxy empfängt eine Anfrage vom Client. Der HTTP(S)-Proxy wertet die Anfrage mithilfe der URL-Zuordnung aus, um Entscheidungen zum Routing des Traffics zu treffen. Der Proxy kann auch die Kommunikation mithilfe von SSL-Zertifikaten authentifizieren.

    • Beim HTTPS-Load-Balancing verwendet der HTTPS-Zielproxy SSL-Zertifikate, um seine Identität gegenüber Clients nachzuweisen. Ein HTTPS-Zielproxy unterstützt bis zu einer dokumentierten Anzahl von SSL-Zertifikaten.

  • Der HTTP(S)-Proxy verwendet eine URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Basierend auf der Routingentscheidung leitet der Proxy Clientanfragen an bestimmte Back-End-Dienste oder Back-End-Buckets weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, z. B. Weiterleitungen an Clients.

  • Ein Backend-Dienst verteilt Anfragen an fehlerfreie Backends. Die globalen externen Application Load Balancer unterstützen auch Backend-Buckets. Ein oder mehrere Back-Ends müssen mit dem Back-End-Dienst oder Back-End-Bucket verbunden sein.

  • Eine 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 Ihre Back-Ends, um Systemdiagnoseprüfungen zu akzeptieren. Regionale externe Application Load Balancer erfordern eine zusätzliche Firewallregel, damit Traffic vom Nur-Proxy-Subnetz die Back-Ends erreichen kann.

Global

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines globalen externen Application Load Balancers. Diese Architektur gilt sowohl für den globalen externen Application Load Balancer als auch für den klassischen Application Load Balancer in der Premium-Stufe.

Komponenten des globalen externen Application Load Balancers
Komponenten eines globalen externen Application Load Balancers (zum Vergrößern klicken).
Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen Application Load Balancers.

Komponenten eines regionalen externen Application Load Balancers
Komponenten eines regionalen externen Application Load Balancers (zum Vergrößern klicken).

Nur-Proxy-Subnetz

Nur-Proxy-Subnetze sind nur für regionale externe Application Load Balancer erforderlich.

Das Nur-Proxy-Subnetz stellt 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 regionale externe Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in derselben Region und demselben VPC-Netzwerk teilen einen Pool von Envoy-Proxys aus demselben Nur-Proxy-Subnetz. Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Backend-VMs bzw. Endpunkte aller regionalen externen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse des regionalen externen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine extern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.
  • Nur-Proxy-Subnetze können mit dem Stack-Typ IPV4_IPV6 oder IPV4_ONLY konfiguriert werden.

Wenn Sie zuvor ein Nur-Proxy-Subnetz mit --purpose=INTERNAL_HTTPS_LOAD_BALANCER erstellt haben, müssen Sie den Zweck des Subnetzes zu REGIONAL_MANAGED_PROXY migrieren, bevor Sie andere Envoy-basierte Load-Balancer in derselben Region des VPC-Netzwerks erstellen können.

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, einer URL-Zuordnung und mindestens einem Back-End-Dienst besteht.

Angabe der IP-Adresse Jede Weiterleitungsregel stellt eine einzelne IP-Adresse bereit, die in DNS-Einträgen für die Anwendung verwendet werden kann. Ein Load-Balancing für DNS ist nicht erforderlich. Sie können die zu verwendende IPv4- oder IPv6-Adresse entweder selbst angeben oder von Cloud Load Balancing zuweisen lassen.

Portspezifikation Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe externe IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP(S)-Proxy verweisen, solange die gesamte Kombination von IP-Adresse, Port und Protokoll für jede Weiterleitungsregel eindeutig ist. Auf diese Weise können Sie einen einzelnen Load Balancer mit einer freigegebenen URL-Zuordnung als Proxy für mehrere Anwendungen verwenden.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von externen Application Load Balancern verwendet werden, hängen vom Modus des Load-Balancers und von der Netzwerkdienststufe ab, in der sich der Load-Balancer befindet.

Load-Balancer-Modus Netzwerkdienststufe Weiterleitungsregel, IP-Adresse und Load-Balancing-Schema Routing aus dem Internet zum Frontend des Load-Balancers
Globaler externer Application Load Balancer Premium-Stufe

Globale externe Weiterleitungsregel

Globale externe IP-Adresse

Load-Balancing-Schema:
EXTERNAL_MANAGED

 Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
Klassischer Application Load Balancer Premium-Stufe

Globale externe Weiterleitungsregel

Globale externe IP-Adresse

Load-Balancing-Schema:
EXTERNAL 1

 Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
Standardstufe

Regionale externe Weiterleitungsregel

Regionale externe IP-Adresse

Load-Balancing-Schema:
EXTERNAL1

 Anfragen, die an ein GFE in der Region des Load-Balancers weitergeleitet werden
Regionaler externer Application Load Balancer Premium-Stufe oder Standard-Stufe

Regionale externe Weiterleitungsregel

Regionale externe IP-Adresse

Load-Balancing-Schema:
EXTERNAL_MANAGED

 Anfragen erreichen Google Cloud am PoP, der dem Client am nächsten ist. Anfragen werden dann über das Premium-Backbone von Google Cloudweitergeleitet, bis sie Envoy-Proxys in derselben Region wie der Load-Balancer erreichen.
1 Es ist möglich, EXTERNAL_MANAGED-Backend-Dienste an EXTERNAL-Weiterleitungsregeln anzuhängen. EXTERNAL-Backend-Dienste können jedoch nicht an EXTERNAL_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, Ihre vorhandenen EXTERNAL-Ressourcen zu EXTERNAL_MANAGED zu migrieren. Verwenden Sie dazu den Migrationsprozess, der unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren beschrieben wird.

Eine vollständige Liste der Protokolle, die von Weiterleitungsregeln des externen Application Load Balancers in den einzelnen Modi unterstützt werden, finden Sie unter Load-Balancer-Features.

Weiterleitungsregeln und VPC-Netzwerke

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

Load-Balancer-Modus VPC-Netzwerkzuordnung
Globaler externer Application Load Balancer

Klassischer Application Load Balancer

Kein zugehöriges VPC-Netzwerk.

Die Weiterleitungsregel verwendet immer eine IP-Adresse, die sich außerhalb des VPC-Netzwerk befindet. Daher ist der Weiterleitungsregel kein VPC-Netzwerk zugeordnet.
Regionaler externer Application Load Balancer

Das VPC-Netzwerk der Weiterleitungsregel ist das Netzwerk, in dem das Nur-Proxy-Subnetz erstellt wurde. Sie geben das Netzwerk an, wenn Sie die Weiterleitungsregel erstellen.

Je nachdem, ob Sie eine IPv4-Adresse oder einen IPv6-Adressbereich verwenden, ist der Weiterleitungsregel immer ein explizites oder implizites VPC-Netzwerk zugeordnet.

  • Regionale externe IPv4-Adressen befinden sich immer außerhalb von VPC-Netzwerken. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie jedoch das VPC-Netzwerk angeben, in dem das Nur-Proxy-Subnetz erstellt wurde. Daher hat die Weiterleitungsregel eine explizite Netzwerkzuordnung.

  • Regionale externe IPv6-Adressbereiche sind immer in einem VPC-Netzwerk vorhanden. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie das Subnetz angeben, aus dem der IP-Adressbereich stammt. Dieses Subnetz muss sich in derselben Region und im selben VPC-Netzwerk befinden, in der bzw. in dem ein Nur-Proxy-Subnetz erstellt wurde. Daher besteht eine implizite Netzwerkzuordnung.

    Netzwerk- und Subnetzanforderungen Für IPv6-Traffic müssen Ihr Netzwerk und Ihre Subnetze die folgenden Konfigurationsanforderungen erfüllen:

    • VPC-Netzwerk: Sie müssen ein VPC-Netzwerk im benutzerdefinierten Modus verwenden, das mit dem Flag --enable-ula-internal-ipv6 konfiguriert ist.
    • Subnetz der Weiterleitungsregel: Dieses Subnetz muss ein Dual-Stack-Subnetz (IPv4_IPv6) oder ein IPV6_ONLY-Subnetz sein, wobei ipv6-access-type auf EXTERNAL festgelegt ist.

    Optionen für die Zuweisung von IPv6-Adressen Die Weiterleitungsregel muss auf einen /96-Bereich von IPv6-Adressen aus dem externen /64-IPv6-Adressbereich des Subnetzes verweisen.

    Einschränkungen Wenn Sie eine benutzerdefinierte temporäre IPv6-Adresse angeben möchten, müssen Sie die Google Cloud CLI oder die API verwenden. In der Google Cloud Konsole können keine benutzerdefinierten kurzlebigen IPv6-Adressen für Weiterleitungsregeln angegeben werden.

Zielproxys

Zielproxys beenden HTTP(S)-Verbindungen von Clients. Mindestens eine Weiterleitungsregel leitet den Traffic zum Zielproxy und der Zielproxy ruft die URL-Zuordnung auf, um zu ermitteln, wie Traffic an Back-Ends weitergeleitet wird.

Der Proxy behält die Groß- und Kleinschreibung im Namen eines Anfrage- oder Antwortheaders nicht unbedingt bei. Beispiel: Der Antwortheader Server: Apache/1.0 könnte auf dem Client als server: Apache/1.0 angezeigt werden.

In der folgenden Tabelle ist der Typ des Zielproxys angegeben, der für externe Application Load Balancer erforderlich ist.

Load-Balancer-Modus Ziel-Proxytypen Vom Proxy hinzugefügte Header Unterstützte benutzerdefinierte Header
Globaler externer Application Load Balancer Globales HTTP,
globales HTTPS		 Die Proxys richten HTTP-Anfrage-/Antwortheader so ein:
  • Via: 1.1 google (Anfragen und Antworten)
  • X-Forwarded-Proto: [http | https] (nur Anfragen)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen)

Die Proxys legen auch den X-Cloud-Trace-Context-Header fest, falls er noch nicht vorhanden ist.

 Im Backend-Dienst oder Backend-Bucket konfiguriert

Wird nicht von Cloud CDN
Klassischer Application Load Balancer Globales HTTP,
globales HTTPS		 Die Proxys richten HTTP-Anfrage-/Antwortheader so ein:
  • Via: 1.1 google (Anfragen und Antworten)
  • X-Forwarded-Proto: [http | https] (nur Anfragen)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen)

Die Proxys legen auch den X-Cloud-Trace-Context-Header fest, falls er noch nicht vorhanden ist.

 Im Backend-Dienst oder Backend-Bucket konfiguriert
Regionaler externer Application Load Balancer Regionaler HTTP,
Regionaler HTTPS
  • X-Forwarded-Proto: [http | https] (nur Anfragen)
  • Via: 1.1 google (Anfragen und Antworten)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (siehe X-Forwarded-For-Header) (nur Anfragen)
In der URL-Zuordnung konfiguriert

Zusätzlich zu den Headern, die vom Zielproxy hinzugefügt werden, werden andere HTTP-Header vom Load-Balancer auf folgende Weise angepasst:

  • Für den globalen externen Application Load Balancer werden sowohl Anfrage- als auch Antwortheader möglicherweise in Kleinbuchstaben umgewandelt.

    Die einzige Ausnahme bildet die Verwendung globaler Internet-NEG-Backends mit HTTP/1.1. Weitere Informationen zur Verarbeitung von HTTP/1.1-Headern mit globalen Internet-NEGs finden Sie in der Übersicht über Internet-NEGs.

  • Für den klassischen Application Load Balancer werden Anfrage- und Antwortheader nur in Kleinbuchstaben umgewandelt, wenn Sie HTTP/1.1 verwenden. Bei HTTP/1.1 werden Header stattdessen in der richtigen Schreibweise angegeben. Der erste Buchstabe im Schlüssel des Headers und jeder Buchstabe nach einem Bindestrich (-) werden groß geschrieben, um die Kompatibilität mit HTTP/1.1-Clients zu wahren. Beispiel: user-agent wird in User-Agent geändert und content-encoding in Content-Encoding.

  • Einige Header werden zusammengeführt. Wenn mehrere Instanzen mit demselben Headerschlüssel vorhanden sind, z. B. Via, kombiniert der Load-Balancer deren Werte in einer durch Kommas getrennten Liste zu einem einzelnen Headerschlüssel. Es werden nur Header zusammengeführt, deren Werte als durch Kommas getrennte Liste dargestellt werden können. Andere Header wie Set-Cookie werden nie zusammengeführt.

Host-Header

Wenn der Load-Balancer die HTTP-Anfrage stellt, behält der Load-Balancer den Host-Header der ursprünglichen Anfrage bei.

X-Forwarded-For-Header

Der Load-Balancer hängt zwei IP-Adressen, die durch ein einzelnes Komma getrennt sind, in der folgenden Reihenfolge an den Header X-Forwarded-For an:

  1. Die IP-Adresse des Clients, der eine Verbindung zum Load-Balancer herstellt
  2. Die IP-Adresse der Weiterleitungsregel des Load-Balancers

Wenn die eingehende Anfrage keinen X-Forwarded-For-Header enthält, sieht der resultierende Header so aus:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Wenn die eingehende Anfrage bereits einen X-Forwarded-For-Header enthält, hängt der Load-Balancer seine Werte an den vorhandenen Header an:

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>
Achtung: