Traffic-Verwaltung für regionale externe Application Load Balancer einrichten

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 unterstützte Application Load Balancer in Diensterweiterungen eingebunden, damit Sie benutzerdefinierte Logik in den Load Balancing-Datenpfad einfügen können.

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 ausgewählter Funktion müssen Sie entweder eine YAML-Datei für eine URL-Zuordnung, eine YAML-Datei für einen Backend-Dienst oder beides schreiben.

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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

URL-Weiterleitung konfigurieren

Im folgenden Beispiel wird ein konfigurierbarer 301-MOVED_PERMANENTLY_DEFAULT-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.

Wenn Sie eine Weiterleitung für einen Backend-Bucket erstellen möchten, verwenden Sie projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET für das Feld defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       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. Das bedeutet, dass der Load Balancer nicht auf eine Antwort vom Back-End wartet, an das er die gespiegelte Anfrage sendet. Die Anfragespiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Back-End-Dienstes anstatt in der Produktionsversion zu beheben.

Standardmäßig erhält der gespiegelte Backend-Dienst alle Anfragen, auch wenn der ursprüngliche Traffic auf mehrere gewichtete Backend-Dienste aufgeteilt wird. Sie können den gespiegelten Back-End-Dienst so konfigurieren, dass er nur einen Prozentsatz der Anfragen empfängt.Verwenden Sie dazu das optionale Flag mirrorPercent, um den Prozentsatz der zu spiegelnden Anfragen als Wert zwischen 0 und 100,0 anzugeben. Die prozentualbasierte Spiegelung von Anfragen befindet sich in der Vorabversion.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Wenn Sie mehrere gewichtete Backend-Dienste haben und aufzeichnen möchten, welcher Backend-Dienst für die ursprüngliche Anfrage verwendet wurde, können Sie allen Anfragen einen benutzerdefinierten Header mit diesen Informationen hinzufügen. 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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

Beachten Sie bei der Verwendung des Traffic-Mirrorings die folgenden Einschränkungen:

• Die Traffic-Spiegelung wird unterstützt, wenn beide Backend-Dienste verwaltete Instanzgruppen, zonale NEGs oder Hybrid-NEGs als Backends haben. Sie wird nicht für Internet-NEGs, serverlose NEGs und Private Service Connect-Backends unterstützt.
• Anfragen an den gespiegelten Back-End-Dienst generieren keine Logs oder Messwerte für Cloud Logging und Cloud Monitoring.

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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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

Hinweis: Wir haben eine Änderung im Verhalten für benutzerdefinierte Header angekündigt, die in URL-Zuordnungen und Backend-Diensten konfiguriert sind. Diese Änderung wirkt sich nicht auf Projekte aus, in denen Traffic vorhanden war, der vor dem 14. November 2022 benutzerdefinierte Header verwendet hat. Weitere Informationen finden Sie im Versionshinweis vom 14. November 2022.

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: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/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

Hinweis: Konfigurieren Sie die Sitzungsaffinität nicht, wenn Sie die gewichtete Trafficaufteilung verwenden. In diesem Fall hat die Konfiguration der gewichteten Trafficaufteilung Vorrang.

In diesem Beispiel werden die folgenden Schritte veranschaulicht:

1. Unterschiedliche Vorlagen für verschiedene Dienste erstellen

2. Instanzgruppen für diese Vorlagen erstellen

3. Routingregeln erstellen, die 95 % bzw. 5 % Trafficteilung einrichten

4. 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 an green-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 Run-Funktionen 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

1. Öffnen Sie in der Google Cloud Console die Seite Load-Balancing.
   Gehe zu „Load-Balancing“
2. Klicken Sie auf den Link global-lb-map.
3. Klicken Sie auf Bearbeiten .

Neue Routingregeln konfigurieren

1. Wählen Sie unter Routingregeln die Option Erweiterte Host-, Pfad- und Routeregel aus.
2. Erstellen Sie unter Tool zum Abgleich von neuen Hosts und Pfaden die Standardaktion. Setzen Sie dazu den Dienst auf red-service.
3. Klicken Sie auf Fertig.
4. Klicken Sie auf Tool zum Abgleich von Hosts und Pfaden hinzufügen.
5. Geben Sie im Feld Hosts die IP-Adresse der Weiterleitungsregel Ihres Load-Balancers ein.

6. Fügen Sie den folgenden YAML-Inhalt in das Feld Pfad-Matcher ein:

   defaultService: projects/PROJECT_ID/global/backendServices/red-service
   name: matcher1
   routeRules:
   - priority: 2
     matchRules:
       - prefixMatch: /PREFIX
     routeAction:
       weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/green-service
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/blue-service
           weight: 5
   

7. Klicken Sie auf Fertig.

8. Klicken Sie auf Aktualisieren.

gcloud

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

2. 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: projects/PROJECT_ID/global/backendServices/red-service
     name: matcher1
     routeRules:
     - priority: 2
       matchRules:
         - prefixMatch: /PREFIX
       routeAction:
         weightedBackendServices:
           - backendService: projects/PROJECT_ID/global/backendServices/green-service
             weight: 95
           - backendService: projects/PROJECT_ID/global/backendServices/blue-service
             weight: 5
   

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

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

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

3. Fügen Sie in der Datei red-service-config.yaml die folgende Zeile ein:

   sessionAffinity: NONE
   

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

Nächste Schritte

• Einrichtung des Load-Balancers bereinigen