Dieses Dokument enthält für bestimmte Anwendungsfälle Beispiele für die Verwendung der Trafficverwaltung. Darüber hinaus sind noch weitere Anwendungsfälle möglich.
Das Dokument enthält Beispiele für globale externe Application Load Balancer.
Globale externe Application Load Balancer verwenden das Load-Balancing-Schema EXTERNAL_MANAGED
und globale Load-Balancing-Komponenten wie Weiterleitungsregel, URL-Zuordnung und Backend-Dienst.
Informationen zur Traffic-Verwaltung mit einem klassischen Application Load Balancer finden Sie in der Übersicht zur Traffic-Verwaltung für einen klassischen Application Load Balancer.
Informationen zur Traffic-Verwaltung mit globalen externen Application Load Balancern finden Sie in der Übersicht zur Traffic-Verwaltung für globale externe Application Load Balancer.
Zusätzlich zu den auf dieser Seite beschriebenen erweiterten Routingfunktionen sind bestimmte Anwendungs-Load-Balancer in Diensterweiterungen eingebunden, damit Sie benutzerdefinierte Logik in den Load-Balancing-Datenpfad einfügen können, indem Sie Dienst-Erweiterungs-Callouts konfigurieren.
Hinweise
Machen Sie sich mit der Funktionsweise der Trafficverwaltung vertraut. Weitere Informationen finden Sie in der Übersicht zur Traffic-Verwaltung für globale externe Application Load Balancer.
Traffic-Verwaltung konfigurieren und testen
In der ausgewählten Konfigurationsumgebung richten Sie die Trafficverwaltung mithilfe von YAML-Konfigurationen ein. Eine URL-Zuordnung und ein Backend-Dienst haben jeweils eine eigene YAML-Datei. Je nach gewünschter Funktion muss entweder eine YAML-Datei für eine URL-Zuordnung, eine YAML-Datei für einen Backend-Dienst oder beides geschrieben werden.
Wenn Sie Hilfe beim Schreiben dieser YAML-Dateien benötigen, können Sie die Beispiele auf dieser Seite und die Cloud Load Balancing API-Dokumentation verwenden.
Die Google Cloud Console wird nicht unterstützt.
Die Dokumentation zur globalen URL Map API und zur globalen Back End Service API enthält eine vollständige Liste der Felder, einschließlich der Semantik in Bezug auf Beziehungen, Einschränkungen und Kardinalität.
Sie können einer URL-Zuordnung Konfigurationstests hinzufügen, damit Ihre URL-Zuordnung Anfragen wie vorgesehen weiterleitet. Sie können mit verschiedenen URL-Zuordnungsregeln experimentieren und so viele Tests wie nötig ausführen, damit die Zuordnung den Traffic an den entsprechenden Back-End-Dienst oder Back-End-Bucket weiterleitet. Weitere Informationen finden Sie unter Tests zu einer URL-Zuordnung hinzufügen. Wenn Sie Änderungen an einer URL-Zuordnung testen möchten, ohne die Karte tatsächlich bereitzustellen, finden Sie weitere Informationen unter Konfiguration der URL-Zuordnung prüfen.
Traffic einem einzelnen Dienst zuordnen
Der gesamte Traffic wird an einen einzelnen Dienst gesendet. Achten Sie darauf, dass Sie die Platzhalter ersetzen.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
Traffic auf zwei Dienste aufteilen
Teilen Sie Traffic auf zwei oder zwischen mehreren Diensten auf. Achten Sie darauf, dass Sie die Platzhalter ersetzen.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
URL-Weiterleitung konfigurieren
Im folgenden Beispiel wird ein konfigurierbarer 3xx-Antwortcode zurückgegeben. Außerdem wird der Antwortheader Location
mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
hostRedirect: "new-host-name.com" # Omit to keep the requested host
pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
redirectResponseCode: FOUND
stripQuery: True
Trafficspiegelung
Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Backend-Dienst können Sie eine identische Anfrage an den konfigurierten Spiegel-Backend-Dienst auf Fire-and-Forget-Basis senden. Der Load-Balancer wartet nicht auf eine Antwort vom Backend, an den die gespiegelte Anfrage gesendet wird. Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Backend-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Backend-Dienstes anstatt in der Produktionsversion zu beheben.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_2
Die Trafficspiegelung wird für Folgendes unterstützt:
- Verwaltete Instanzgruppen, zonale NEGs und hybride NEGs-Back-Ends. Für Internet-NEGs, serverlose NEGs und Private Service Connect-Back-Ends wird es nicht unterstützt.
- HTTP-Anfragen ohne Textkörper.
Die Spiegelung kann nicht nur für einen bestimmten Teil der Anfragen konfiguriert werden. Auch wenn Sie den Traffic auf mehrere gewichtete Backend-Dienste aufteilen, erhält der Spiegel-Backend-Dienst alle Anfragen. Sie können jedoch benutzerdefinierte Header verwenden, um aufzuzeichnen, welcher Backend-Dienst für die ursprüngliche Anfrage verwendet wurde. Im folgenden Beispiel wird allen Clientanfragen ein benutzerdefinierter Header mit dem Namen x-weighted-picked-backend
hinzugefügt. Verwenden Sie für den Headerwert den Namen des Backend-Dienstes, von dem die ursprüngliche Anfrage verarbeitet wurde.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_1
replace: True
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_2
replace: True
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_3
Angeforderte URL umschreiben
Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Backend-Dienst gesendet wird. Achten Sie darauf, dass Sie die Platzhalter ersetzen.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
Anfrage wiederholen
Die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum Neuversuch sowie die maximal zulässige Anzahl von Wiederholungsversuchen werden konfiguriert.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Routenzeitlimit angeben
Gibt die Zeitüberschreitung für die ausgewählte Route an. Das Zeitlimit wird ab der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 0
Fehlerinjektion konfigurieren
Fehler können in die Verarbeitung von Anfragen eingebracht werden, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Dieses Feature ist hilfreich, um die Ausfallsicherheit eines Diensts gegenüber simulierten Störungen zu testen.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 0
percentage: 25
abort:
httpStatus: 503
percentage: 50
CORS konfigurieren
Richtlinien werden für Cross-Origin Resource Sharing (CORS) konfiguriert, um Einstellungen für die Durchsetzung von CORS-Anfragen zu verarbeiten.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: [ "http://my-domain.com" ]
allowMethods: [ "GET", "POST" ]
allowHeaders: [ "Authorization", "Content-Type" ]
maxAge: 1200
allowCredentials: true
Anfrage- und Antwortheader hinzufügen und entfernen
Fügen Sie Anfrageheader hinzu und entfernen Sie sie, bevor Sie eine Anfrage an den Backend-Service senden. Außerdem können Antwort-Header hinzugefügt oder entfernt werden, nachdem eine Antwort vom Backend-Dienst empfangen wurde.
Für headerName
und headerValue
gelten Einschränkungen für gültige Werte.
Weitere Informationen finden Sie unter Funktionsweise benutzerdefinierter Header.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Ausreißererkennung konfigurieren
Kriterien für das Entfernen fehlerhafter Backend-VMs oder Endpunkte in NEGs werden festgelegt sowie die Kriterien dafür, wann ein Backend oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen. Achten Sie darauf, dass Sie die Platzhalter ersetzen.
loadBalancingScheme: EXTERNAL_MANAGED
localityLbPolicy: RANDOM
name: global/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: 30
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: 1
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
Trafficaufteilung einrichten: detaillierte Schritte
In diesem Beispiel werden die folgenden Schritte veranschaulicht:
Unterschiedliche Vorlagen für verschiedene Dienste erstellen
Instanzgruppen für diese Vorlagen erstellen
Routingregeln erstellen, die 95 % bzw. 5 % Trafficteilung einrichten
curl-Befehle senden, mit denen Sie prüfen, ob die Prozentwerte für die Trafficaufteilung ungefähr der Konfiguration entsprechen
Bei dieser Anleitung wird Folgendes vorausgesetzt:
Ein Zielproxy und eine Weiterleitungsregel wurden zusammen mit einer URL-Zuordnung mit dem Namen
global-lb-map
erstellt.Die URL-Zuordnung sendet den gesamten Traffic an einen Backend-Dienst mit dem Namen
red-service
. Dies ist der Standard-Backend-Dienst.Sie haben einen alternativen Pfad eingerichtet, der 5 % des Traffics an
blue-service
und 95 % des Traffics angreen-service
sendet.Es wird ein Pfad-Abgleichstool verwendet.
Sie verwenden Cloud Shell oder eine andere Umgebung, in der bash installiert ist.
Dienste definieren
Die folgende bash-Funktion erstellt einen Backend-Dienst, einschließlich der Instanzvorlage und der verwalteten Instanzgruppe.
Bei dieser Anleitung wird davon ausgegangen, dass eine HTTP-Systemdiagnose (global-lb-basic-check
) erstellt wurde. Eine Anleitung finden Sie auf einer der folgenden Seiten:
- Globalen externen Application Load Balancer mit einem Compute Engine-Backend einrichten
- Globalen externen Application Load Balancer mit einem Backend-Bucket einrichten
- Globalen externen Application Load Balancer mit Hybridkonnektivität einrichten
- Globalen externen Application Load Balancer mit Cloud Run, App Engine oder Cloud Functions einrichten
function make_service() { local name="$1" local region="$2" local zone="$3" local network="$4" local subnet="$5" local subdir="$6" www_dir="/var/www/html/$subdir" (set -x; \ gcloud compute instance-templates create "${name}-template" \ --region="$region" \ --network="$network" \ --subnet="$subnet" \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script="#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl sudo mkdir -p $www_dir /bin/hostname | sudo tee ${www_dir}index.html systemctl restart apache2"; \ gcloud compute instance-groups managed create \ "${name}-instance-group" \ --zone="$zone" \ --size=2 \ --template="${name}-template"; \ gcloud compute backend-services create "${name}-service" \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=global-lb-basic-check \ --global \ gcloud compute backend-services add-backend "${name}-service" \ --balancing-mode='UTILIZATION' \ --instance-group="${name}-instance-group" \ --instance-group-zone="$zone" \ --global) }
Erstellen Sie die Dienste:
Rufen Sie die Funktion auf, um drei Dienste zu erstellen: red
, green
und blue
. Der Dienst red
dient als Standarddienst für Anfragen an /
. Die Dienste green
und blue
werden beide unter /prefix
für 95 % bzw. 5 % des Traffics eingerichtet.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /prefix make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix
URL-Zuordnung erstellen
Console
- Öffnen Sie in der Google Cloud Console die Seite Load-Balancing.
Gehe zu „Load-Balancing“ - Klicken Sie auf den Link global-lb-map.
- Klicken Sie auf Bearbeiten .
Neue Routingregeln konfigurieren
- Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.
- Erstellen Sie unter Tool zum Abgleich von neuen Hosts und Pfaden die Standardaktion. Setzen Sie dazu den Dienst auf
red-service
. - Klicken Sie auf Fertig.
- Klicken Sie auf Tool zum Abgleich von Hosts und Pfaden hinzufügen.
- Geben Sie im Feld Hosts die IP-Adresse der Weiterleitungsregel Ihres Load-Balancers ein.
Fügen Sie den folgenden YAML-Inhalt in das Feld Pfad-Matcher ein:
defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5
Klicken Sie auf Fertig.
Klicken Sie auf Aktualisieren.
gcloud
Exportieren Sie die vorhandene URL-Zuordnung mit dem Befehl
gcloud compute url-maps export
:gcloud compute url-maps export global-lb-map \ --destination=global-lb-map-config.yaml \ --global
Aktualisieren Sie die URL-Zuordnungsdatei
global-lb-map-config.yaml
. Fügen Sie dazu Folgendes am Ende der Datei hinzu:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5
Aktualisieren Sie mit dem Befehl
gcloud compute url-maps import
die URL-Zuordnung:gcloud compute url-maps import global-lb-map \ --global \ --source=global-lb-map-config.yaml
Konfiguration testen
Testen Sie die Konfiguration. Achten Sie als Erstes darauf, dass Anfragen an die IP-Adresse des Load-Balancers, die zuvor eingerichtet wurde, von der Standardkonfiguration red
verarbeitet werden.
Prüfen Sie dann, ob an FORWARDING_RULE_IP_ADDRESS/prefix
gesendete Anfragen wie erwartet aufgeteilt werden.
Sitzungsaffinität anhand von HTTP_COOKIE
einrichten
Mit der Trafficsteuerung können Sie die Sitzungsaffinität anhand eines bereitgestellten Cookies konfigurieren. In diesem Beispiel wird eine auf HTTP_COOKIE basierende Sitzungsaffinität für einen Backend-Dienst mit dem Namen red-service
konfiguriert.
Verwenden Sie den Befehl
gcloud compute backend_services export
, um die Konfiguration des Backend-Dienstes abzurufen.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --global
Aktualisieren Sie die Datei
red-service-config.yaml
so:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 0 minimumRingSize: 10000
Fügen Sie in der Datei
red-service-config.yaml
die folgende Zeile ein:sessionAffinity: NONE
Aktualisieren Sie die Konfigurationsdatei für den Backend-Dienst:
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --global
Fehlerbehebung
Gehen Sie nach den hier beschriebenen Informationen zur Fehlerbehebung vor, wenn der Traffic nicht gemäß den von Ihnen konfigurierten Routingregeln und Trafficrichtlinien weitergeleitet wird.
Informationen zu Logging und Monitoring finden Sie unter Externes HTTP(S)-Logging und -Monitoring.
Symptome:
- Vermehrter Traffic an Dienste in Regeln über der betreffenden Regel
- Unerwartet vermehrte 4xx- und 5xx-HTTP-Antworten für eine bestimmte Routingregel
Lösung: Überprüfen Sie die Reihenfolge Ihrer Routingregeln. Routingregeln werden in der Reihenfolge interpretiert, in der sie angegeben sind.
Routingregeln innerhalb einer URL-Zuordnung werden in der Reihenfolge ihrer Angabe interpretiert. Pfadregeln hingegen werden nach Abgleich mit dem längsten Präfix interpretiert. Bei einer Pfadregel wählt der globale externe Application Load Balancer nur eine einzelne Pfadregel aus. Wenn Sie jedoch Routingregeln verwenden, gelten möglicherweise mehrere.
Achten Sie beim Definieren von Routingregeln darauf, dass die Regeln oben in der Liste nicht versehentlich Traffic weiterleiten, der andernfalls von einer nachfolgenden Routingregel weitergeleitet worden wäre. Der Dienst, der fehlgeleiteten Traffic empfängt, würde wahrscheinlich Anfragen ablehnen. Der Dienst in Ihren Routenregeln würde weniger oder keinen Traffic erhalten.