Ü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 vonTrusted 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

Dieser Load Balancer ist im regionalen Modus verfügbar und wird im Folgenden als regionaler externer Application Load Balancer bezeichnet. Der Load Balancer ist als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung und anfrage- oder antwortbasierte Headertransformationen. Der regionale Modus sorgt dafür, dass sich alle Clients und Backends in einer bestimmten Region befinden. Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen.

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.

• 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.

Regional

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

Nur-Proxy-Subnetz

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.

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 IP-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.

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, VPC-Netzwerken zugeordnet 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.

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

• 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>

Vorhandene Header-Werte mit einem benutzerdefinierten Anfrage-Header entfernen

Vorhandene Headerwerte können mithilfe von benutzerdefinierten Anfrageheadern im Back-End-Dienst entfernt werden. Im folgenden Beispiel wird das Flag --custom-request-header verwendet, um den X-Forwarded-For-Header mit den Variablen client_ip_address und server_ip_address neu zu erstellen. Bei dieser Konfiguration wird der eingehende X-Forwarded-For-Header durch die IP-Adresse des Clients und des Load-Balancers ersetzt.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Wie Back-End-Reverse-Proxy-Software den X-Forwarded-For-Header ändern kann

Wenn auf den Back-Ends Ihres Load-Balancers eine HTTP-Reverse-Proxy-Software ausgeführt wird, kann die Software eine oder beide der folgenden IP-Adressen an das Ende des Headers X-Forwarded-For anhängen:

1. Die IP-Adresse des GFE, das mit dem Backend verbunden ist. GFE-IP-Adressen liegen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16.

2. Die IP-Adresse des Backend-Systems.

Daher kann ein vorgelagertes System einen X-Forwarded-For-Header mit folgender Struktur sehen:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Cloud Trace-Unterstützung

Trace wird bei Application Load Balancern nicht unterstützt. Globale und klassische Application Load Balancer fügen den X-Cloud-Trace-Context-Header hinzu, falls er nicht vorhanden ist. Der regionale externe Application Load Balancer fügt diesen Header nicht hinzu. Wenn der X-Cloud-Trace-Context-Header bereits vorhanden ist, wird er unverändert an die Load-Balancer weitergeleitet. Der Load-Balancer exportiert jedoch keine Traces oder Spans.

URL-Zuordnungen

URL-Zuordnungen definieren die Zuordnungsmuster für eine Weiterleitung von Anfragen, die auf URLs basieren, an die passenden Back-End-Dienste. Mit der URL-Zuordnung können Sie Ihren Traffic aufteilen. Dazu werden die URL-Komponenten untersucht, damit sie Anfragen an verschiedene Back-End-Sets senden. Ein Standarddienst ist so definiert, dass er alle Anfragen bearbeiten kann, für die es keine bestimmte Host- oder Pfadregel gibt.

URL-Zuordnungen unterstützen mehrere erweiterte Funktionen zur Trafficverwaltung wie Header-basierte Trafficsteuerung, gewichtete Trafficaufteilung und Anfragespiegelung. Hier finden Sie weitere Informationen:

• Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer

In der folgenden Tabelle ist der Typ der URL-Zuordnung angegeben, der von externen Application Load Balancern in den einzelnen Modi benötigt wird.

SSL-Zertifikate

Externe Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

Regionale externe Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

Regionale externe Application Load Balancer unterstützen selbstverwaltete Compute Engine-SSL-Zertifikate.

SSL-Richtlinien

SSL-Richtlinien geben die SSL-Features an, die Trusted Cloud Load-Balancer beim Aushandeln von SSL mit Clients verwenden.

Standardmäßig verwendet der HTTPS-Load-Balancer eine Reihe von SSL-Funktionen, die eine hohe Sicherheit und umfassende Kompatibilität bieten. Einige Anwendungen erfordern mehr Kontrolle darüber, welche SSL-Versionen und -Chiffren für ihre HTTPS- oder SSL-Verbindungen verwendet werden. Sie können eine SSL-Richtlinie definieren, um die Gruppe von SSL-Features anzugeben, die der Load-Balancer beim Aushandeln von SSL mit Clients verwendet. Darüber hinaus können Sie diese SSL-Richtlinie auf Ihren Ziel-HTTPS-Proxy anwenden.

In der folgenden Tabelle ist die Unterstützung von SSL-Richtlinien für Load-Balancer in den einzelnen Modi aufgeführt.

Backend-Dienste

Ein Backend-Dienst stellt dem Load-Balancer Konfigurationsinformationen bereit, damit er Anfragen an seine Backends weiterleiten kann, z. B. an Compute Engine-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs). Weitere Informationen zu Backend-Diensten finden Sie unter Übersicht über Backend-Dienste.

Bereich des Back-End-Dienstes

In der folgenden Tabelle ist angegeben, welche Backend-Dienstressource und welcher Bereich von externen Application Load Balancern verwendet werden:

Protokoll für Back-Ends

Für Backend-Dienste für Application Load Balancer muss eines der folgenden Protokolle verwendet werden, um Anfragen an Back-Ends zu senden:

• HTTP, das HTTP/1.1 und kein TLS verwendet
• HTTPS, das HTTP/1.1 und TLS verwendet
• HTTP/2, das HTTP/2 und TLS verwendet (HTTP/2 ohne Verschlüsselung wird nicht unterstützt).
• H2C, das HTTP/2 über TCP verwendet. TLS ist nicht erforderlich. H2C wird für klassische Application Load Balancer nicht unterstützt.

Der Load-Balancer verwendet nur das von Ihnen angegebene Backend-Dienstprotokoll für die Kommunikation mit seinen Backends. Der Load-Balancer greift nicht auf ein anderes Protokoll zurück, wenn er mit dem angegebenen Backend-Dienstprotokoll nicht mit den Backends kommunizieren kann.

Das Protokoll des Back-End-Diensts muss nicht mit dem Protokoll übereinstimmen, das von Clients für die Kommunikation mit dem Load-Balancer verwendet wird. Clients können beispielsweise Anfragen mit HTTP/2 an den Load-Balancer senden, der Load-Balancer kann jedoch mit Back-Ends über HTTP/1.1 (HTTP oder HTTPS) kommunizieren.

Back-Ends

Ein regionaler externer Application Load Balancer unterstützt die folgenden Arten von Backends:

• Instanzgruppen
• Zonale NEGs
• Internet-NEGs

Back-Ends und VPC-Netzwerke

Für Back-Ends regionaler externer Application Load Balancer gilt Folgendes:

• 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. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel oder Cloud Interconnect-VLAN-Anhänge konfiguriert werden.

  Definition des Backend-Netzwerks

  • Bei zonalen NEGs und Hybrid-NEGs geben Sie das VPC-Netzwerk explizit an, wenn Sie die NEG erstellen.
  • 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 Back-Ends 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 von den Backend-Instanzen oder ‑Endpunkten verwendeten Subnetzen zu ermöglichen.

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

  Regionale externe Application Load Balancer unterstützen auch Umgebungen mit freigegebener VPC, in denen Sie VPC-Netzwerke und die zugehörigen Ressourcen projektübergreifend freigeben können. Wenn sich der Backend-Dienst und die Backends des regionalen externen Application Load Balancers in einem anderen Projekt als die Weiterleitungsregel befinden sollen, müssen Sie den Load Balancer in einer freigegebenen VPC-Umgebung mit projektübergreifendem Dienstverweis konfigurieren.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an Nicht-nic0-Schnittstellen (entweder vNICs oder dynamische Netzwerkschnittstellen) 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.

Systemdiagnosen

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.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Backend-Instanzen erreichen können. In der Regel gehen Systemdiagnoseprüfungen vom zentralen Systemdiagnosemechanismus von Google aus.

Regionale externe Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, sind eine Ausnahme von dieser Regel, da ihre Systemdiagnosen stattdessen vom Nur-Proxy-Subnetz ausgehen. Weitere Informationen finden Sie in der Übersicht zu Hybrid-NEGs.

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 HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Im Gegensatz dazu unterstützen regionale externe Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.

Weitere Informationen zu Systemdiagnosen finden Sie hier:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen

Firewallregeln

Für den Load Balancer sind die folgenden Firewallregeln erforderlich:

• Für den regionalen externen Application Load Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um den Traffic aus dem Nur-Proxy-Subnetz zu Ihren Back-Ends zuzulassen.
• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Bereichen der Systemdiagnoseprüfungen zuzulassen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können Trusted Cloud Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load Balancer erreicht.

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.

GKE-Unterstützung

GKE verwendet externe Application Load Balancer auf folgende Weise:

• Externe Gateways, die mit dem GKE-Gateway-Controller erstellt wurden, können jeden Modus eines externen Application Load Balancer verwenden. Sie steuern den Modus des Load Balancers, indem Sie eine GatewayClass auswählen. Der GKE-Gateway-Controller verwendet immer zonale NEG-Back-Ends (GCE_VM_IP_PORT).

• Sie können zonale GCE_VM_IP_PORT-NEGs, die von GKE-Diensten erstellt und verwaltet werden, als Back-Ends für jeden Application Load Balancer oder Proxy-Network-Load-Balancer verwenden. Weitere Informationen finden Sie unter Containernatives Load-Balancing über eigenständige zonale NEGs.

Architektur einer freigegebenen VPC

Externe Application Load Balancer unterstützen Netzwerke, die eine freigegebene VPC verwenden. Eine freigegebene VPC ermöglicht Organisationen, Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, einen externen Application Load Balancer in einem freigegebenen VPC-Netzwerk zu konfigurieren. Unabhängig vom Bereitstellungstyp müssen sich alle Komponenten des Load-Balancers in derselben Organisation befinden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebene VPC-Hostprojekt erstellen, aber die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung werden bei diesem Modell nicht getrennt.

Alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt

Das folgende Architekturdiagramm zeigt eine standardmäßige Bereitstellung einer freigegebenen VPC, bei der sich alle Load-Balancer-Komponenten und Backends in einem Dienstprojekt befinden. Dieser Bereitstellungstyp wird von allen Application Load Balancern unterstützt.

Die Komponenten und Back-Ends des Load-Balancers müssen dasselbe VPC-Netzwerk verwenden.

Projektübergreifender Dienstverweis

Projektübergreifender Dienst, der auf verweist, ist ein Bereitstellungsmodell, bei dem sich das Frontend und die URL-Zuordnung des Load-Balancers in einem Projekt und der Backend-Dienst und die Backends des Load-Balancers in einem anderen Projekt befinden.

Mit projektübergreifenden Dienstreferenzen können Organisationen einen zentralen Load-Balancer konfigurieren und Traffic an Hunderte von Diensten weiterleiten, die über mehrere verschiedene Projekte verteilt sind. Sie können alle Regeln und Richtlinien für das Traffic-Routing zentral in einer URL-Zuordnung verwalten. Sie können den Load-Balancer auch mit einem einzelnen Satz von Hostnamen und SSL-Zertifikaten verknüpfen. Sie können daher die Anzahl der für die Bereitstellung Ihrer Anwendung erforderlichen Load-Balancer optimieren und die Verwaltungs-, Betriebskosten- und Kontingentanforderungen reduzieren.

Wenn Sie für jedes Ihrer funktionalen Teams unterschiedliche Projekte verwenden, können Sie auch eine Trennung der Rollen innerhalb Ihrer Organisation erreichen. Dienstinhaber können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während Netzwerkteams Load-Balancer in einem anderen Projekt bereitstellen und verwalten können. Beide Dienste können über projektübergreifende Dienstreferenzen verbunden werden.

Dienstinhaber können die Autonomie der Freigabe ihrer Dienste aufrechterhalten und steuern, welche Nutzer über den Load-Balancer auf ihre Dienste zugreifen können. Dies wird durch eine spezielle IAM-Rolle mit der Bezeichnung Nutzer von Compute-Load-Balancer-Diensten (roles/compute.loadBalancerServiceUser) erreicht.

Die Unterstützung für projektübergreifende Dienstverweise variiert je nach Load-Balancer-Typ:

• Für globale externe Application Load Balancer: Das Frontend und die URL-Zuordnung Ihres Load Balancers können auf Backend-Dienste oder Backend-Buckets aus einem beliebigen Projekt innerhalb derselben Organisation verweisen. Es gelten keine Einschränkungen für VPC-Netzwerke. Sie können zwar eine freigegebene VPC-Umgebung verwenden, um eine projektübergreifende Bereitstellung zu konfigurieren, wie in diesem Beispiel gezeigt, dies ist jedoch keine Voraussetzung.

• Für regionale externe Application Load Balancer: Sie müssen den Load Balancer in einer freigegebenen VPC-Umgebung erstellen. Das Frontend und die URL-Zuordnung des Load-Balancers müssen sich in einem Host- oder Dienstprojekt befinden. Die Backend-Dienste und Backends des Load-Balancers können auf Host- oder Dienstprojekte in derselben Umgebung mit freigegebener VPC verteilt werden.

Informationen zum Konfigurieren der freigegebene VPC für einen regionalen externen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Regionalen externen Application Load Balancer mit freigegebener VPC einrichten.

Hinweise zur Verwendung des projektübergreifenden Dienstverweises

• Trusted Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie also projektübergreifende Dienstverweise verwenden, empfehlen wir, in allen Projekten Ihrer Organisation eindeutige Backend-Dienstnamen zu verwenden.
• Wenn Sie einen Fehler wie „Cross-project references for this resource are not allowed“ (Projektübergreifende Verweise für diese Ressource sind nicht zulässig) sehen, prüfen Sie, ob Sie die Berechtigung zur Verwendung der Ressource haben. Ein Administrator des Projekts, zu dem die Ressource gehört, muss Ihnen die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser) zuweisen. Diese Rolle kann auf Projekt- oder Ressourcenebene zugewiesen werden. Ein Beispiel finden Sie unter Dem Compute-Load-Balancer-Administrator die Berechtigungen erteilen, den Backend-Dienst oder Backend-Bucket zu verwenden.

Beispiel 1: Load-Balancer-Frontend und -Backend in verschiedenen Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung einer freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load-Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

Beispiel 2: Load-Balancer-Frontend im Hostprojekt und Back-Ends in Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung mit freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt werden.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

Beispiel 3: Load-Balancer-Frontend und -Back-Ends in verschiedenen Projekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, bei der das Frontend und die URL-Zuordnung des globalen externen Application Load Balancers in einem anderen Projekt als der Backend-Dienst und die Backends des Load Balancers erstellt werden. Bei dieser Art der Bereitstellung wird keine freigegebene VPC verwendet und sie wird nur für globale externe Application Load Balancer unterstützt.

Weitere Informationen zu dieser Einrichtung finden Sie unter Projektübergreifende Dienstreferenzierung mit einem Back-End-Dienst und einem Back-End-Bucket einrichten.

Hochverfügbarkeit und Failover

Hochverfügbarkeit und Failover in externen Application Load Balancern können auf Load-Balancer-Ebene konfiguriert werden. Dazu werden regionale externe Sicherungs-Application Load Balancer in jeder Region erstellt, in der Sie eine Sicherung benötigen.

In der folgenden Tabelle wird das Failover-Verhalten beschrieben.

HTTP/2-Unterstützung

HTTP/2 ist eine wesentliche Überarbeitung des HTTP/1-Protokolls. Es gibt zwei Modi für die HTTP/2-Unterstützung:

• HTTP/2 über TLS
• HTTP/2-Klartext über TCP

HTTP/2 über TLS

HTTP/2 über TLS wird für Verbindungen zwischen Clients und dem externen Application Load Balancer sowie für Verbindungen zwischen dem Load Balancer und seinen Backends unterstützt.

Der Load Balancer verhandelt automatisch HTTP/2 mit Clients als Teil des TLS-Handshakes und verwendet dazu die ALPN TLS-Erweiterung. Auch wenn ein Load-Balancer für die Verwendung von HTTPS konfiguriert ist, verwenden moderne Clients standardmäßig HTTP/2. Dies wird auf dem Client gesteuert, nicht auf dem Load Balancer.

Wenn ein Client HTTP/2 nicht unterstützt und der Load Balancer für die Verwendung von HTTP/2 zwischen dem Load Balancer und den Backend-Instanzen konfiguriert ist, kann er trotzdem eine HTTPS-Verbindung aushandeln oder ungesicherte HTTP-Anfragen akzeptieren. Diese HTTPS- oder HTTP-Anfragen werden dann vom Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Wenn Sie HTTP/2 über TLS verwenden möchten, müssen Sie TLS auf Ihren Back-Ends aktivieren und das Back-End-Dienstprotokoll auf HTTP2 festlegen. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Maximale Anzahl gleichzeitiger HTTP/2-Streams

Die HTTP/2-Einstellung SETTINGS_MAX_CONCURRENT_STREAMS beschreibt die maximale Anzahl von Streams, die ein Endpunkt akzeptiert, die vom Peer initiiert wurden. Der von einem HTTP/2-Client zu einemTrusted Cloud -Load-Balancer angekündigte Wert hat quasi keine Bedeutung, da der Load-Balancer keine Streams an den Client initiiert.

In Fällen, in denen der Load-Balancer HTTP/2 für die Kommunikation mit einem Server verwendet, der auf einer VM ausgeführt wird, berücksichtigt der Load-Balancer den vom Server angekündigten Wert SETTINGS_MAX_CONCURRENT_STREAMS. Wenn ein Wert von null angekündigt wird, kann der Load-Balancer keine Anfragen an den Server weiterleiten. Das kann zu Fehlern führen.

HTTP/2-Einschränkungen

• HTTP/2 zwischen dem Load-Balancer und der Instanz kann wesentlich mehr TCP-Verbindungen zur Instanz benötigen als HTTP oder HTTPS. Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP oder HTTPS reduziert, ist bei HTTP/2 nicht möglich. Dies kann zu hohen Backend-Latenzen führen, da Backend-Verbindungen häufiger hergestellt werden.
• HTTP/2 zwischen dem Load Balancer und dem Back-End unterstützt nicht das Ausführen des WebSocket-Protokolls über einen einzelnen Stream einer HTTP/2-Verbindung (RFC 8441).
• HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt keinen Server-Push.
• Die gRPC-Fehlerrate und das Anfragevolumen sind in derTrusted Cloud API oder der Trusted Cloud Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und die Monitoring-Daten den HTTP-Statuscode 200 OK.

HTTP/2-Klartext über TCP (H2C)

Mit Cleartext HTTP/2 über TCP, auch als H2C bezeichnet, können Sie HTTP/2 ohne TLS verwenden. H2C wird für beide der folgenden Verbindungen unterstützt:

• Verbindungen zwischen Clients und dem Load-Balancer. Es ist keine spezielle Konfiguration erforderlich.

• Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.

  Wenn Sie H2C für Verbindungen zwischen dem Load Balancer und seinen Backends konfigurieren möchten, legen Sie das Backend-Dienstprotokoll auf H2C fest.

H2C-Unterstützung ist auch für Load Balancer verfügbar, die mit dem GKE-Gateway-Controller und Cloud Service Mesh erstellt wurden.

H2C wird für klassische Application Load Balancer nicht unterstützt.

WebSocket-Unterstützung

Trusted Cloud HTTP(S)-basierte Load Balancer unterstützen das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Backend verwenden. Der Load-Balancer benötigt zum Weiterleiten von WebSocket-Verbindungen über einen Proxy keine Konfiguration.

Das WebSocket-Protokoll bietet einen Vollduplex-Kommunikationskanal zwischen Clients und dem Load Balancer. Weitere Informationen finden Sie unter RFC 6455.

Das WebSocket-Protokoll funktioniert so:

1. Der Load-Balancer erkennt eine WebSocket-Upgrade-Anfrage von einem HTTP- oder HTTPS-Client. Die Anfrage enthält die Header Connection: Upgrade und Upgrade: websocket, gefolgt von anderen relevanten WebSocket-bezogenen Anfrageheadern.
2. Das Backend sendet eine WebSocket-Upgrade-Antwort. Die Backend-Instanz sendet eine 101 switching protocol-Antwort mit Connection: Upgrade- und Upgrade: websocket-Headern und anderen WebSocket-bezogenen Antwortheadern.
3. Der Load Balancer leitet für die Dauer der aktuellen Verbindung bidirektionalen Traffic über einen Proxy weiter.

Wenn die Back-End-Instanz den Statuscode 426 oder 502 zurückgibt, schließt der Load-Balancer die Verbindung.

Die Sitzungsaffinität für WebSockets funktioniert wie für jede andere Anfrage. Weitere Informationen finden Sie unter Sitzungsaffinität.

gRPC-Unterstützung

gRPC ist ein Open Source-Framework für Remoteprozeduraufrufe. Es basiert auf dem HTTP/2-Standard. Anwendungsfälle für gRPC sind:

• Hoch skalierbare, verteilte Systeme mit geringer Latenz
• Entwicklung mobiler Clients, die mit einem Cloud-Server kommunizieren
• Entwurf neuer Protokolle, die genau, effizient und sprachunabhängig sein müssen
• Layerdesign, um Erweiterung, Authentifizierung und Protokollierung zu ermöglichen

Um gRPC mit Ihren Trusted Cloud -Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. Dazu erstellen Sie einen Application Load Balancer mit einer der folgenden Konfigurationen:

• Für unverschlüsselten End-to-End-Traffic (ohne TLS): Sie erstellen einen HTTP-Load-Balancer (der mit einem HTTP-Zielproxy konfiguriert ist). Außerdem konfigurieren Sie den Load-Balancer so, dass er HTTP/2 für unverschlüsselte Verbindungen zwischen dem Load-Balancer und seinen Back-Ends verwendet, indem Sie das Protokoll des Back-End-Dienstes auf H2C festlegen.

• Für End-to-End-verschlüsselten Traffic (mit TLS): Sie erstellen einen HTTPS-Load-Balancer (konfiguriert mit einem HTTPS-Zielproxy und einem SSL-Zertifikat). Der Load Balancer handelt im Rahmen des SSL-Handshakes HTTP/2 mit Clients aus und verwendet dazu die ALPN TLS-Erweiterung.

  Außerdem müssen Sie dafür sorgen, dass die Back-Ends TLS-Traffic verarbeiten können, und den Load-Balancer so konfigurieren, dass er HTTP/2 für verschlüsselte Verbindungen zwischen dem Load-Balancer und seinen Back-Ends verwendet. Dazu müssen Sie das Back-End-Dienstprotokoll auf HTTP2 festlegen.

  Der Load-Balancer kann mit einigen Clients weiter HTTPS aushandeln oder unsichere HTTP-Anfragen auf einem Load-Balancer akzeptieren, der für die Verwendung von HTTP/2 zwischen dem Load-Balancer und den Backend-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Informationen zum Konfigurieren eines Application Load Balancers mit HTTP/2 mit Google Kubernetes Engine Ingress oder mit gRPC und HTTP/2 finden Sie unter HTTP/2 für Load-Balancing mit Ingress.

Informationen zum Konfigurieren eines externen Application Load Balancers mit HTTP/2 mit Cloud Run finden Sie unter HTTP/2 hinter einem Load-Balancer verwenden.

Informationen zur Fehlerbehebung bei HTTP/2 finden Sie unter Fehlerbehebung für HTTP/2 zu den Back-Ends.

Informationen zu Einschränkungen von HTTP/2 finden Sie unter HTTP/2-Einschränkungen.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Zielproxy nur TLS 1.0, 1.1, 1.2 und 1.3, wenn SSL-Requests von Clients beendet werden.

Wenn der klassische Application Load Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 mit dem Back-End aushandeln.

Unterstützung von gegenseitigem TLS

Gegenseitiges TLS (Mutual TLS, mTLS) ist ein Branchenstandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. mTLS trägt dazu bei, dass sowohl der Client als auch der Server sich gegenseitig authentifizieren, indem sie überprüfen, ob jeder ein gültiges Zertifikat besitzt, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, erfordert mTLS, dass sowohl der Client als auch der Server Zertifikate präsentieren, um die Identitäten beider Parteien zu bestätigen, bevor eine Kommunikation hergestellt wird.

Alle Application Load Balancer unterstützen mTLS. Bei mTLS fordert der Load-Balancer an, dass der Client während des TLS-Handshakes mit dem Load-Balancer ein Zertifikat sendet, um sich zu authentifizieren. Sie können einen Certificate Manager-Trust Store konfigurieren, mit dem der Load-Balancer die Vertrauenskette des Clientzertifikats validiert.

Weitere Informationen zu mTLS finden Sie unter Gegenseitige TLS-Authentifizierung.

Unterstützung von TLS 1.3 Early Data

TLS 1.3 Early Data wird im HTTPS-Zielproxy der folgenden externen Application Load Balancer sowohl für HTTPS über TCP (HTTP/1.1, HTTP/2) als auch für HTTP/3 über QUIC unterstützt:

• Globale externe Application Load Balancer
• Klassische Application Load Balancer

TLS 1.3 wurde in RFC 8446 definiert und führt das Konzept der frühen Daten ein, auch bekannt als Zero-Round-Trip-Time-Daten (0-RTT). Dadurch kann die Anwendungsleistung bei wiederaufgenommenen Verbindungen um 30 bis 50 % verbessert werden.

Mit TLS 1.2 sind zwei Roundtrips erforderlich, bevor Daten sicher übertragen werden können. Bei TLS 1.3 wird dies auf eine Umlaufzeit (1-RTT) für neue Verbindungen reduziert. Clients können Anwendungsdaten also sofort nach der ersten Serverantwort senden. Außerdem wird mit TLS 1.3 das Konzept der Early Data für fortgesetzte Sitzungen eingeführt. Dadurch können Clients Anwendungsdaten mit dem ersten ClientHello senden und so die effektive Round-Trip-Zeit auf null (0-RTT) reduzieren. Mit TLS 1.3 Early Data kann der Backend-Server mit der Verarbeitung von Clientdaten beginnen, bevor der Handshake-Prozess mit dem Client abgeschlossen ist. Dadurch wird die Latenz verringert. Es muss jedoch darauf geachtet werden, dass das Risiko von Replay-Angriffen minimiert wird.

Da frühe Daten gesendet werden, bevor der Handshake abgeschlossen ist, kann ein Angreifer versuchen, Anfragen abzufangen und wiederzugeben. Um dies zu verhindern, muss der Backend-Server die Nutzung von frühen Daten sorgfältig steuern und auf idempotente Anfragen beschränken. HTTP-Methoden, die idempotent sein sollen, aber nicht idempotente Änderungen auslösen können, z. B. eine GET-Anfrage, mit der eine Datenbank geändert wird, dürfen keine Early Data akzeptieren. In solchen Fällen muss der Backend-Server Anfragen mit dem HTTP-Header Early-Data: 1 ablehnen, indem er den HTTP-Statuscode 425 Too Early zurückgibt.

Bei Anfragen mit Early Data ist der HTTP-Header „Early-Data“ auf den Wert 1 gesetzt. Dies signalisiert dem Backend-Server, dass die Anfrage in TLS Early Data übertragen wurde. Außerdem wird angegeben, dass der Client den HTTP-Statuscode 425 Too Early versteht.

TLS Early Data-Modi (0-RTT)

Sie können TLS Early Data mit einem der folgenden Modi in der Ziel-HTTPS-Proxyressource des Load-Balancers konfigurieren.

• STRICT. Dadurch werden TLS 1.3 Early Data für Anfragen mit sicheren HTTP-Methoden (GET, HEAD, OPTIONS, TRACE) und HTTP-Anfragen ohne Suchparameter aktiviert. Anfragen, bei denen Early Data mit nicht idempotenten HTTP-Methoden (z. B. POST oder PUT) oder mit Abfrageparametern gesendet werden, werden mit dem HTTP-Statuscode 425 abgelehnt.

• PERMISSIVE. Dadurch werden TLS 1.3 Early Data für Anfragen mit sicheren HTTP-Methoden (GET, HEAD, OPTIONS, TRACE) aktiviert. In diesem Modus werden Anfragen mit Abfrageparametern nicht abgelehnt. Der Anwendungsbesitzer muss dafür sorgen, dass die frühen Daten für jeden Anfragepfad sicher verwendet werden können, insbesondere für Endpunkte, bei denen die Wiederholung von Anfragen unbeabsichtigte Nebeneffekte wie Protokollierung oder Datenbankaktualisierungen durch GET-Anfragen verursachen kann.

• DISABLED: TLS 1.3 Early Data wird nicht beworben und alle (ungültigen) Versuche, Early Data zu senden, werden abgelehnt. Wenn Ihre Anwendungen nicht in der Lage sind, frühe Datenanfragen sicher zu verarbeiten, müssen Sie frühe Daten deaktivieren. TLS 1.3 Early Data ist standardmäßig deaktiviert.

• UNRESTRICTED (für die meisten Arbeitslasten nicht empfohlen). Dadurch werden TLS 1.3-Early Data für Anfragen mit beliebigen HTTP-Methoden aktiviert, einschließlich nicht idempotenter Methoden wie POST. Dieser Modus erzwingt keine weiteren Beschränkungen. Dieser Modus kann für gRPC-Anwendungsfälle nützlich sein. Wir empfehlen diese Methode jedoch nur, wenn Sie Ihren Sicherheitsstatus bewertet und das Risiko von Replay-Angriffen mit anderen Mechanismen verringert haben.

TLS Early Data konfigurieren

So aktivieren oder deaktivieren Sie TLS Early Data explizit:

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Nachdem Sie TLS Early Data konfiguriert haben, können Sie Anfragen von einem HTTP-Client senden, der TLS Early Data unterstützt. Bei fortgesetzten Anfragen ist die Latenz möglicherweise geringer.

Wenn ein nicht RFC-konformer Client eine Anfrage mit einer nicht idempotenten Methode oder mit Suchparametern sendet, wird die Anfrage abgelehnt. In den Load-Balancer-Logs wird der HTTP-Statuscode 425 Early und die folgende HTTP-Antwort angezeigt:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Beschränkungen

• HTTPS-Load-Balancer senden keine Benachrichtigung zum Schließen close_notify, wenn SSL-Verbindungen beendet werden. Das heißt, der Load-Balancer schließt die TCP-Verbindung, statt einen SSL-Shutdown auszuführen.

• HTTPS-Load-Balancer unterstützen nur Kleinbuchstaben in Domains mit einem gemeinsamen Namen (CN) oder einem alternativen Antragstellernamen (SAN) des Zertifikats. Zertifikate mit Großbuchstaben in Domains werden nur zurückgegeben, wenn sie als Primäres Zertifikat im Zielproxy.

• HTTPS-Load-Balancer verwenden beim Herstellen einer Verbindung zum Backend nicht die Erweiterung „Server Name Indication“ (SNI), mit Ausnahme von Load-Balancern mit Internet-NEG-Backends. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

• Trusted Cloud garantiert nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

• Wenn Sie einen regionalen externen Application Load Balancer in der Premium-Stufe mit derTrusted Cloud Console erstellen, sind in der Trusted Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Für den Zugriff auf andere Regionen verwenden Sie entweder die gcloud CLI oder die API.

Nächste Schritte

• Informationen zum Bereitstellen eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

• Informationen zum Konfigurieren erweiterter Trafficverwaltungsfunktionen, die mit dem regionalen externen Application Load Balancer verfügbar sind, finden Sie unter Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer.