Übersicht über die Trafficverwaltung für interne HTTP(S)-Load-Balancer

Das interne HTTP(S)-Load-Balancing unterstützt erweiterte Funktionen zur Trafficverwaltung, sodass Sie die folgenden Funktionen nutzen können:
  • Trafficsteuerung: Intelligente Weiterleitung von Traffic auf Basis von HTTP(S)-Parametern, z. B. Host, Pfad, Header und andere Anfrageparameter
  • Trafficaktionen: Ausführen anfrage- und antwortbasierter Aktionen, z. B. Weiterleitungen und Headertransformationen
  • Trafficrichtlinien: Optimieren des Load-Balancing-Verhaltens, z. B. erweiterte Load-Balancing-Algorithmen

Sie können diese Funktionen mithilfe von URL-Zuordnungen und Back-End-Diensten einrichten. Weitere Informationen finden Sie unter folgenden Links:

Fallbeispiele

Die Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Trafficsteuerung: Routing auf Basis von Headern

Mithilfe der Trafficsteuerung können Sie Traffic anhand von HTTPS-Parametern wie Anfrageheadern zu Dienstinstanzen leiten. Wenn das Gerät eines Nutzers beispielsweise ein Mobilgerät mit user-agent:Mobile im Anfrageheader ist, kann die Trafficsteuerung diesen Traffic an Dienstinstanzen senden, die zur Verarbeitung von mobilem Traffic bestimmt sind. Traffic ohne user-agent:Mobile wird wiederum an Instanzen zur Verarbeitung von Traffic anderer Geräte gesendet.

Trafficsteuerung für Cloud Load Balancing (zum Vergrößern klicken)
Trafficsteuerung für Cloud Load Balancing

Trafficaktionen: Gewichtete Trafficaufteilung

Die Bereitstellung einer neuen Version eines bestehenden Produktionsdienstes birgt in der Regel ein gewisses Risiko. Selbst wenn die Tests in der Staging-Phase positiv ausfallen, möchten Sie wahrscheinlich nicht sofort 100 % Ihrer Nutzer die neue Version verwenden lassen. Mit dem internen HTTP(S)-Load-Balancing können Sie prozentuale Trafficaufteilungen für mehrere Back-End-Dienste definieren.

Sie können beispielsweise 95 % des Traffics an die vorherige Version Ihres Dienstes und 5 % an die neue Version Ihres Dienstes senden. Nachdem Sie sich vergewissert haben, dass die neue Produktionsversion wie erwartet funktioniert, können Sie die Prozentsätze schrittweise ändern, bis 100 % des Traffics die neue Version Ihres Dienstes erreichen. Die Trafficaufteilung wird gewöhnlich zur Bereitstellung neuer Versionen, für A/B-Tests, Dienstmigration und ähnliche Prozesse verwendet.

Cloud Load Balancing – Trafficaufteilung
Trafficaufteilung in Cloud Load Balancing

Trafficrichtlinien: Anfragespiegelung

Ihre Organisation hat möglicherweise bestimmte Compliance-Anforderungen, die festlegen, dass der gesamte Traffic auf einen zusätzlichen Dienst gespiegelt wird, der z. B. die Anfragedetails zur späteren erneuten Verwendung in einer Datenbank erfasst.

Trafficverwaltung – Komponenten

Im Allgemeinen bieten interne HTTP(S)-Load-Balancer eine Funktion zur Trafficverwaltung über die Ressourcen für regionale URL-Zuordnungen und regionale Back-End-Dienste.

Sie können die Trafficsteuerung und Trafficaktionen mithilfe regionaler URL-Zuordnungen einrichten. Google Cloud-Ressourcen, die mit URL-Zuordnungen verknüpft sind, umfassen Folgendes:

  • Routingregel
  • Regelübereinstimmung
  • Regelaktion

Sie können Trafficrichtlinien mithilfe regionaler Back-End-Dienste einrichten. Google Cloud-Ressourcen, die mit Back-End-Diensten verknüpft sind, umfassen Folgendes:

  • Load-Balancer-Richtlinie für Standorte
  • Konsistente Einstellungen für den Hash-Load-Balancer
  • Schutzschalter
  • Ausreißererkennung
Im folgenden Diagramm sind die Ressourcen dargestellt, die zur Implementierung der einzelnen Funktionen verwendet werden.

Trafficsteuerung für Cloud Load Balancing (zum Vergrößern klicken)
Cloud Load Balancing-Datenmodell (zum Vergrößern klicken)

Routinganfragen an Back-Ends

Beim internen HTTP(S)-Load-Balancing wird das Back-End für Ihren Traffic mithilfe eines zweiphasigen Ansatzes ermittelt:

  • Der Load-Balancer wählt einen Back-End-Dienst mit Back-Ends aus. Die Back-Ends können Compute Engine-VM-Instanzen in einer nicht verwalteten Instanzgruppe, Compute Engine-VMs in einer verwalteten Instanzgruppe (Managed Instance Group, MIG) oder Container über Google Kubernetes Engine-Knoten (GKE) in einer Netzwerk-Endpunktgruppe (NEG) sein. Der Load-Balancer wählt einen Back-End-Dienst anhand von Regeln aus, die in einer regionalen URL-Zuordnung definiert sind.
  • Der Back-End-Dienst wählt anhand von Richtlinien, die in einem regionalen Back-End-Dienst definiert sind, eine Back-End-Instanz aus.

Beim Konfigurieren des Routings können Sie zwischen den folgenden Modi wählen:

  • Einfache Host- und Pfadregeln
  • Erweiterte Host-, Pfad- und Routingregel

Für jede URL-Zuordnung können Sie einfache Host- und Pfadregeln oder erweiterte Host-, Pfad- und Routingregeln verwenden. Die beiden Modi schließen sich gegenseitig aus. Jede URL-Zuordnung kann jeweils nur einen der Modi enthalten.

Einfache Host- und Pfadregeln

In einer einfachen Host- und Pfadregel funktionieren URL-Zuordnungen wie unter Übersicht über URL-Zuordnungen beschrieben.

Das folgende Diagramm zeigt den logischen Ablauf einer einfachen Host- und Pfadregel.

Einfache URL-Zuordnung
Einfache URL-Zuordnung

Eine Anfrage wird erst einmal mithilfe von Hostregeln ausgewertet. Ein Host ist die in der Anfrage angegebene Domain. Wenn die Anfrage host mit einem der Einträge im Feld hosts übereinstimmt, wird der zugehörige Pfad-Matcher verwendet.

Als Nächstes wird der Pfad-Matcher ausgewertet. Pfadregeln werden nach dem Prinzip "längster Pfad zuerst" abgeglichen. Sie können Pfadregeln in beliebiger Reihenfolge angeben. Nachdem die genaueste Übereinstimmung gefunden wurde, wird die Anfrage an den entsprechenden Back-End-Dienst weitergeleitet. Wenn die Anfrage nicht übereinstimmt, wird der Standard-Back-End-Dienst verwendet.

Eine typische einfache Host- und Pfadregel sieht in etwa so aus, wobei der Videotraffic wird auf video-backend-service und der gesamte andere Traffic auf web-backend-service übertragen wird.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Erweiterte Host-, Pfad- und Routingregel

Erweiterte Host-, Pfad- und Routingregeln bieten im Vergleich zu einfachen Host- und Pfadregeln zusätzliche Konfigurationsoptionen. Diese Optionen ermöglichen erweiterte Trafficverwaltungsmuster und ändern auch einen Teil der Semantik. Routingregeln wird z. B. ein Prioritätswert zugewiesen und sie werden in Prioritätsreihenfolge interpretiert (statt anhand des Prinzips "längster Pfad zuerst").

Wie im vorherigen Beispiel für einfache Host- und Pfadregeln können Sie die erweiterte Trafficverwaltung mithilfe einer regionalen URL-Zuordnung konfigurieren. Die folgende URL-Zuordnung konfiguriert z. B. ein Routing, bei dem 95 % des Traffics an einen Back-End-Dienst und 5 % des Traffics an einen anderen Back-End-Dienst weitergeleitet werden.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

Hostregeln

Wenn eine Anfrage beim Load-Balancer eingeht, wird das Feld host der Anfrage mit dem in der URL-Zuordnung definierten Wert hostRules abgeglichen. Jede Hostregel besteht aus einer Liste mit einem oder mehreren Hosts und einem einzelnen Pfad-Matcher (pathMatcher). Wenn keine hostRules definiert sind, wird die Anfrage an defaultService weitergeleitet.

Weitere Informationen finden Sie unter hostRules[] und defaultService in der API-Dokumentation für regionale URL-Zuordnungen.

Pfad-Matcher

Wenn eine Anfrage mit einer Hostregel übereinstimmt, wertet der Load-Balancer den Pfad-Matcher aus, der dem Host entspricht.

Ein Pfad-Matcher besteht aus Folgendem:

  • Einer oder mehrerer Pfadregeln (pathRules) oder Routingregeln (routeRules).
  • Einem Standarddienst (defaultService), der standardmäßig als Back-End-Dienst verwendet wird, wenn keine Übereinstimmung mit anderen Back-End-Diensten besteht.
Weitere Informationen finden Sie unter pathMatchers[], pathMatchers[].pathRules[] und pathMatchers[].routeRules[] in der API-Dokumentation für regionale URL-Zuordnungen.

Pfadregeln

Pfadregeln (pathRules) geben einen oder mehrere URL-Pfade an, z. B. / oder /video. Pfadregeln sind im Allgemeinen für das zuvor beschriebene host- und pfadbasierte Routing vorgesehen.

Weitere Informationen finden Sie unter pathRules[] in der API-Dokumentation für regionale URL-Zuordnungen.

Routingregeln

Eine Routingregel (routeRules) gleicht Informationen in einer eingehenden Anfrage ab und trifft anhand der Übereinstimmung eine Routingentscheidung.

Routingregeln können eine Vielzahl verschiedener Übereinstimmungsregeln (matchRules) und eine Vielzahl verschiedener Routingaktionen (routeAction) enthalten.

Eine Übereinstimmungsregel wertet die eingehende Anfrage anhand des Pfades, der Header und der Abfrageparameter der HTTP(S)-Anfrage aus. Übereinstimmungsregeln unterstützen verschiedene Arten von Übereinstimmungen (z. B. Präfixübereinstimmung) sowie Modifikatoren (z. B. Groß- und Kleinschreibung). So können Sie beispielsweise HTTP(S)-Anfragen an eine Reihe von Back-Ends senden, je nachdem, ob ein benutzerdefinierter HTTP-Header vorhanden ist.

Wenn Sie mehrere Routingregeln haben, führt der Load-Balancer diese in Prioritätsreihenfolge aus (basierend auf dem Feld priority). Dies ermöglicht es Ihnen, benutzerdefinierte Logiken für den Abgleich, das Routing und andere Aktionen anzugeben.

In einer Routingregel beendet der Load-Balancer nach der ersten Übereinstimmung die Auswertung der Übereinstimmungsregeln. Alle verbleibenden Übereinstimmungsregeln werden ignoriert.

Google Cloud führt die folgenden Aktionen aus:

  1. Sucht nach der ersten Übereinstimmungsregel, die der Anfrage entspricht
  2. Beendet die Suche nach anderen Übereinstimmungsregeln
  3. Wendet die Aktionen in den entsprechenden Routingaktionen an

Routingregeln bestehen aus mehreren Komponenten, die in der folgenden Tabelle beschrieben werden.

Komponente der Routingregel (API field name) Beschreibung
Priorität (priority) Eine Zahl von 0 bis 2.147.483.647 (also (2^31)-1), die einer Routingregel innerhalb eines angegebenen Pfad-Matchers zugewiesen ist.

Die Priorität bestimmt die Reihenfolge der Routingregelauswertung. Die Priorität einer Regel nimmt mit zunehmender Anzahl ab, sodass eine Regel mit der Priorität 4 vor einer Regel mit der Priorität 25 ausgewertet wird. Die erste Regel, die der Anfrage entspricht, wird angewendet.

Prioritätsnummern müssen nicht aufeinanderfolgen. Sie können nicht mehr als eine Regel mit derselben Priorität erstellen.
Beschreibung (description) Eine optionale Beschreibung von bis zu 1.024 Zeichen.
Dienst (service) Die vollständige oder Teil-URL der Back-End-Dienstressource, an die der Traffic weitergeleitet wird, wenn diese Regel übereinstimmt.
Übereinstimmungsregeln (matchRules) Eine oder mehrere Regeln, die anhand der Anfrage ausgewertet werden. Diese matchRules können mit allen oder einem Teil der HTTP-Attribute der Anfrage übereinstimmen, z. B. mit den Parametern "Pfad", "HTTP-Header" und "Abfrage (GET)".

Innerhalb einer matchRule müssen alle Übereinstimmungskriterien erfüllt sein, damit die routeActions der routeRule wirksam werden. Besitzt eine routeRule mehrere matchRules, werden die routeActions der routeRule wirksam, wenn eine Anfrage mit einer der matchRules der routeRule übereinstimmt.
Routingaktion (routeAction) Hier können Sie angeben, welche Aktionen ausgeführt werden sollen, wenn die Kriterien der Übereinstimmungsregel erfüllt sind. Zu diesen Aktionen gehören Trafficaufteilung, URL-Überschreibungen, Wiederholungsversuche und Spiegelung, Fehlerinjektion und CORS-Richtlinien.
Weiterleitungsaktion (urlRedirect) Sie können eine Aktion so konfigurieren, dass sie mit einer HTTP-Weiterleitung antwortet, wenn die Kriterien der Übereinstimmungsregel erfüllt sind. Dieses Feld kann nicht in Verbindung mit einer Routingaktion verwendet werden.
Headeraktion (headerAction) Sie können Headertransformationsregeln für Anfragen und Antworten konfigurieren, wenn die Kriterien innerhalb der matchRules erfüllt sind.

Weitere Informationen finden Sie in den folgenden Feldern in der API-Dokumentation für regionale URL-Zuordnungen:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

Übereinstimmungsregeln

Übereinstimmungsregeln (matchRules) stimmen mit einem oder mehreren Attributen einer Anfrage überein und führen die in der Routingregel festgelegten Aktionen aus. Die folgende Liste enthält einige Beispiele für Anfrageattribute, die mithilfe von Übereinstimmungsregeln abgeglichen werden können:

  • Host: Der Hostname ist der Domainnamen-Teil einer URL. Der Hostname der URL http://example.net/video/hd ist beispielsweise example.net. In der Anfrage stammt der Hostname aus dem Header Host, wie in diesem curl-Beispielbefehl gezeigt, wobei 10.1.2.9 die Load-Balancing-IP-Adresse ist:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Die Pfade folgen dem Hostnamen, z. B. /images. Die Regel kann angeben, ob der gesamte Pfad oder nur der führende Teil des Pfads übereinstimmen muss.

  • Andere HTTP-Anfrageparameter wie HTTP-Header, die einen Cookie-Abgleich ermöglichen, sowie Abgleiche, die auf Abfrageparametern beruhen (GET-Variablen).

Eine vollständige Liste der unterstützten Übereinstimmungsregeln finden Sie unter pathMatchers[].routeRules[].matchRules[] in der API-Dokumentation für regionale URL-Zuordnungen.

Routingaktionen

Routingaktionen sind spezifische Aktionen, die ausgeführt werden sollen, wenn eine Routingregel mit den Attributen einer Anfrage übereinstimmt.

Routingaktion (API field name) Beschreibung
Weiterleitungen (urlRedirect) Ein konfigurierbarer 3xx-Antwortcode wird 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.
URL-Umschreibungen (urlRewrite) Der Teil der URL mit dem Hostnamen, dem Pfad oder beide werden umgeschrieben, bevor eine Anfrage an den ausgewählten Back-End-Dienst gesendet wird.
Headertransformationen (headerAction) Fügt Anfrageheader hinzu oder entfernt diese, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwortheader nach Empfang einer Antwort des Back-End-Diensts hinzugefügt oder entfernt werden.
Trafficspiegelung (requestMirrorPolicy) Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst auf Fire-and-Forget-Basis wird hierbei eine identische Anfrage an den konfigurierten Spiegelungs-Back-End-Dienst gesendet. Der Load-Balancer wartet nicht auf eine Antwort des Back-End-Diensts, an den die gespiegelte Anfrage gesendet wird.

Die Spiegelung 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.
Gewichtete Trafficaufteilung (weightedBackendServices) Lässt zu, dass Traffic für eine übereinstimmende Regel an mehrere Back-End-Dienste verteilt wird, proportional zu einer benutzerdefinierten Gewichtung, die dem jeweiligen Back-End-Dienst zugewiesen ist.

Diese Funktion eignet sich zum Konfigurieren abgestufter Bereitstellungen oder von A/B-Tests. Die Routingaktion könnte beispielsweise so konfiguriert werden, dass 99 % des Traffics an einen Dienst gesendet werden, der eine stabile Version einer Anwendung ausführt, während 1 % des Traffics an einen separaten Dienst mit einer neueren Version dieser Anwendung gesendet wird.
Wiederholungsversuche (retryPolicy) Dient zum Konfigurieren von Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, der Wartezeit des Load-Balancers bis zum erneuten Versuch sowie der maximal zulässigen Anzahl an Wiederholungsversuchen.
Zeitlimit (timeout) Gibt das Zeitlimit für die ausgewählte Route an. Das Zeitlimit wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen.
Fehlerinjektion (faultInjectionPolicy) Kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Diese Funktion ist hilfreich, um die Ausfallsicherheit eines Diensts gegenüber simulierten Störungen zu testen.
Verzögerungsinjektion (faultInjectionPolicy) Bringt Verzögerungen für einen benutzerdefinierten Teil von Anfragen ein, bevor die Anfrage an den ausgewählten Back-End-Dienst gesendet wird.
Abbruchinjektion faultInjectionPolicy Reagiert direkt auf einen Teil der Anfragen mit benutzerdefinierten HTTP-Statuscodes, anstatt diese Anfragen an den Back-End-Dienst weiterzuleiten.
Sicherheitsrichtlinien (corsPolicy) Richtlinien für Cross-Origin Resource Sharing (CORS) verarbeiten die Einstellungen für das interne HTTP(S)-Load-Balancing zur Durchsetzung von CORS-Anfragen.

Sie können eine der folgenden Routingaktionen angeben, die in der Google Cloud Console als Primäre Aktionen bezeichnet werden:

  • Traffic an einen einzelnen Dienst weiterleiten (service)
  • Traffic zwischen mehreren Diensten aufteilen (weightedBackendServices weight:x, wobei x < 100 ist)
  • Weiterleitungs-URLs (urlRedirect)

Darüber hinaus können Sie eine der zuvor genannten Routingaktionen mit einer oder mehreren der folgenden Routingaktionen kombinieren. Diese werden in der Cloud Console als Add-on-Aktionen bezeichnet:

  • Trafficspiegelung (requestMirrorPolicy)
  • URL-Host/-Pfad umschreiben (urlRewrite)
  • Fehlgeschlagene Anfragen wiederholen (retryPolicy)
  • Zeitlimit festlegen (timeout)
  • Fehler in einem Prozentsatz des Traffics einführen (faultInjectionPolicy)
  • CORS-Richtlinie hinzufügen (corsPolicy)
  • Anfrage-/Antwortheader bearbeiten (headerAction)

Weitere Informationen zur Konfiguration und Semantik von Routingaktionen finden Sie in den folgenden Abschnitten der API-Dokumentation für regionale URL-Zuordnungen:

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Trafficrichtlinien

Durch die Verwendung von Back-End-Dienstressourcen können Sie Trafficrichtlinien konfigurieren, die ein präzises Load-Balancing innerhalb einer Instanzgruppe oder Netzwerk-Endpunktgruppe (NEG) ermöglichen. Diese Richtlinien werden erst wirksam, nachdem ein Back-End-Dienst mithilfe der regionalen URL-Zuordnung ausgewählt wurde (wie zuvor beschrieben).

Mit Trafficrichtlinien können Sie:

  • Den Load-Balancing-Algorithmus zwischen Instanzen innerhalb des Back-End-Dienstes steuern.
  • Die Anzahl der Verbindungen zu einem vorgelagerten Dienst steuern.
  • Die Bereinigung fehlerhafter Hosts über einen Back-End-Dienst steuern.

Die folgenden Funktionen für Trafficrichtlinien werden im regionalen Back-End-Dienst konfiguriert.

Trafficrichtlinie (API field name) Beschreibung
Load-Balancing-Richtlinie (LocalityLbPolicy) Bei einem Back-End-Dienst beruht die Trafficverteilung auf dem Load-Balancing-Modus und einer Load-Balancing-Richtlinie.

Der Back-End-Dienst leitet den Traffic zuerst gemäß dem Balancing-Modus des Back-Ends an ein Back-End (Instanzgruppe oder NEG) weiter. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß der Load-Balancing-Richtlinie auf Instanzen in diesem Back-End-Dienst verteilt.

Im Balancing-Modus kann der Load-Balancer zuerst einen Ort auswählen, z. B. eine Google Cloud-Zone. Die Load-Balancing-Richtlinie legt dann eine bestimmte Back-End-VM oder einen bestimmten Endpunkt in einer NEG fest.

Verschiedene Load-Balancing-Algorithmen (wie Round Robin, letzte Anfrage und andere) werden unterstützt. Eine vollständige Liste der Algorithmen finden Sie unter localityLbPolicy in der API-Dokumentation für regionale Back-End-Dienste.
Sitzungsaffinität (consistentHash) Umfasst Cookie-basierte HTTP-Affinität, Header-basierte HTTP-Affinität, Client-IP-Adressen-Affinität und Cookie-Affinität. Die Sitzungsaffinität versucht, Anfragen von einem bestimmten Client an dasselbe Back-End zu senden, solange das Back-End intakt ist und Kapazität hat.

Weitere Informationen zur Sitzungsaffinität finden Sie unter consistentHash in der API-Dokumentation für regionale Back-End-Dienste.
Ausreißererkennung (outlierDetection) Eine Reihe von Richtlinien, die die Kriterien für die Bereinigung fehlerhafter Back-End-VMs oder Endpunkte in NEGs sowie Kriterien dafür festlegen, wann ein Back-End oder Endpunkt als stabil genug gilt, um wieder Traffic zu empfangen.

Weitere Informationen zur Sitzungsaffinität finden Sie unter outlierDetection in der API-Dokumentation für regionale Back-End-Dienste.
Schutzschaltung (circuitBreakers) Legt Obergrenzen für die Anzahl der Verbindungen und der Anfragen pro Verbindung an einen Back-End-Dienst fest.

Weitere Informationen zur Sitzungsaffinität finden Sie unter circuitBreakers in der API-Dokumentation für regionale Back-End-Dienste.

Beschränkungen

  • RouteRule.service funktioniert derzeit nicht. Verwenden Sie als Problemumgehung RouteRule.weightedBackendServices mit einem einzelnen WeightedBackendService.
  • Die regulären Pfadausdrücke pathMatchers.routeRules.matchRules.regexMatch werden beim internen HTTP(S)-Load-Balancing nicht unterstützt.
  • UrlMap.defaultRouteAction und UrlMap.defaultUrlRedirect funktionieren derzeit nicht. Sie müssen für die Verarbeitung von Traffic, der mit keinem der Hosts in UrlMap.hostRules[] in diesem UrlMap übereinstimmt, UrlMap.defaultService angeben.
  • UrlMap.pathMatchers[].defaultRouteAction und UrlMap.pathMatchers[].defaultUrlRedirect funktionieren derzeit nicht. Sie müssen für die Verarbeitung von Traffic, der mit keiner der routeRules für diesen pathMatcher übereinstimmt, UrlMap.pathMatchers[].defaultService angeben.
  • Wenn der Wert von BackendService.SessionAffinity nicht NONE lautet und für BackendService.localityLbPolicy eine andere Load-Balancing-Richtlinie als MAGLEV oder RING_HASH festgelegt ist, werden die Einstellungen für die Sitzungsaffinität nicht wirksam.
  • Der Befehl gcloud compute backend-services import löscht nicht die Felder der obersten Ebene der Ressource, also z. B. den Back-End-Dienst und die URL-Zuordnung. Wenn Sie beispielsweise einen Back-End-Dienst mit Einstellungen für circuitBreakers erstellen, können Sie diese Einstellungen mit einem nachfolgenden gcloud compute backend-services import-Befehl aktualisieren. Sie können diese Einstellungen jedoch nicht aus dem Back-End-Dienst löschen. Sie können die Ressource ohne die Einstellungen für circuitBreakers löschen und neu erstellen.

Weitere Informationen

  • Informationen zum Konfigurieren der Trafficverwaltung für das interne HTTP(S)-Load-Balancing finden Sie unter Trafficverwaltung einrichten.