Cloud Load Balancing-Hinweise – Übersicht

Mit Diensterweiterungen können Sie unterstützte Application Load Balancer anweisen, einen Callout vom Load-Balancing-Datenpfad an nutzerverwaltete Callout-Dienste oder Google-Dienste zu senden.

Datenfluss für Callouts

Ein Load-Balancer kommuniziert mit einem Callout über eines der folgenden Envoy-gRPC-Protokolle:

• Das Protokoll für die externe Verarbeitung oder ext_proc.

  Dieses Protokoll wird für Routen-, Verkehrs- und Autorisierungserweiterungen unterstützt und standardmäßig verwendet.

  Mit dem ext_proc-Protokoll kann der Erweiterungsdienst auf Ereignisse im Lebenszyklus einer HTTP-Anfrage reagieren, indem er die Header oder den Text der Anfrage untersucht und ändert.

• Das Protokoll für die externe Autorisierung oder ext_authz.

  Dieses Protokoll wird nur für Autorisierungserweiterungen unterstützt. Die Unterstützung für ext_authz befindet sich in der Vorschau.

  Beim ext_authz-Protokoll werden Autorisierungsentscheidungen für eingehende Anfragen an einen externen, unabhängigen Dienst delegiert. Mit dieser API kann der Erweiterungsdienst auf Ereignisse im Lebenszyklus einer HTTP-Anfrage für komplexe Autorisierungsentscheidungen reagieren, indem er die Header oder Metadaten der Anfrage untersucht.

  Sie können dieses Protokoll mit der Option wireFormat angeben, wenn Sie eine Autorisierungserweiterung konfigurieren.

Sie können diese Erweiterungsdienste auf VM-Instanzen oder in GKE bereitstellen und eine Instanzgruppe oder Netzwerk-Endpunktgruppe (NEG) konfigurieren, um die Endpunkte für diese Dienste darzustellen.

Das folgende Diagramm zeigt, wie Sie den Callout-Back-End-Dienst mit einem gRPC-Server auf einer vom Nutzer verwalteten Computeressource wie einer VM-Instanz oder einem Google Kubernetes Engine-Cluster (GKE) bereitstellen und ihn dem Load Balancer als regulären Back-End-Dienst präsentieren.

Application Load Balancers send Service Extensions callouts to callout backend services (click to enlarge).

Erweiterungen mit Zusatzinformationen in ext_proc

Eine gekürzte Version der ext_proc gRPC API sieht so aus:

// The gRPC API to be implemented by the external processing server
service ExternalProcessor {
  rpc Process(stream ProcessingRequest) returns (stream ProcessingResponse) {
  }
}

// Envoy sets one of these fields depending on the processing stage.
message ProcessingRequest {
  oneof request {
    HttpHeaders request_headers = 2;
    HttpHeaders response_headers = 3;
    HttpBody request_body = 4;
    HttpBody response_body = 5;
  }
}

message ProcessingResponse {
  oneof response {
    HeadersResponse request_headers = 1;
    HeadersResponse response_headers = 2;
    BodyResponse request_body = 3;
    BodyResponse response_body = 4;

    ImmediateResponse immediate_response = 7;
  }
}

Nachdem der Load Balancer die Header für eine HTTP-Anfrage empfangen hat, sendet er die ProcessingRequest-Nachricht an den Erweiterungsdienst. Das Feld request_headers ist auf die HTTP-Header des Clients festgelegt.

Der Erweiterungsdienst muss auf die ProcessingRequest-Nachricht mit einer entsprechenden ProcessingResponse-Nachricht antworten, die alle konfigurierten Änderungen an den Headern oder dem Text der ProcessingRequest-Nachricht enthält. Alternativ kann der Dienst das Feld immediate_response festlegen, damit der Load-Balancer die Verarbeitung der Anfrage beendet und die angegebene Antwort an den Client zurücksendet.

Bei REQUEST_HEADER- und RESPONSE_HEADER-Ereignissen kann der Erweiterungsdienst die HTTP-Header in der Anfrage oder Antwort bearbeiten. Der Dienst kann Header hinzufügen, ändern oder löschen, indem er das Feld request_headers oder response_headers in der ProcessingResponse-Nachricht entsprechend festlegt. Verwenden Sie das Feld raw_value für Header.

Mit Traffic-Erweiterungen können Sie die Header und den Textkörper von Anfragen und Antworten ändern. Der Erweiterungsserver kann den Verarbeitungsmodus dynamisch überschreiben und die Erweiterung für nachfolgende Phasen der Anforderungsverarbeitung aktivieren oder deaktivieren. Load-Balancer werten Routenregeln nach dem Aufrufen einer Traffic-Erweiterung nicht neu aus.

Edge-, Autorisierungs- und Routenerweiterungen unterstützen nur HTTP-Header. Diese Erweiterungen können HTTP-Bodies nicht untersuchen oder ändern.

Erweiterungen mit Zusatzinformationen in ext_authz

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Die ext_authz API unterstützt nur Autorisierungs-Callout-Erweiterungen.

Eine gekürzte Version der API sieht so aus:

// A generic interface for performing authorization checks on incoming
// requests to a networked service.
service Authorization {
  // Performs an authorization check based on the attributes associated with
  // the incoming request and return status.
  rpc Check(CheckRequest) returns (CheckResponse) {
  }
}

message CheckRequest {
  // The request attributes.
  AttributeContext attributes = 1;
}

message CheckResponse {
  google.rpc.Status status = 1;
  oneof http_response {
    DeniedHttpResponse denied_response = 2;
    OkHttpResponse ok_response = 3;
  }
  google.protobuf.Struct dynamic_metadata = 4;
}

Nachdem der Load Balancer die Header für eine HTTP-Anfrage empfangen hat, sendet er die CheckRequest-Nachricht an den Erweiterungsdienst.

Der Erweiterungsdienst muss auf die CheckRequest-Nachricht mit einer entsprechenden CheckResponse-Nachricht antworten, die die folgenden Informationen enthält:

• status: Gibt den Status an. OK gibt an, dass die Anfrage zulässig ist. Jeder andere Status gibt an, dass die Anfrage abgelehnt wurde.

• denied_response oder ok_response: Gibt an, ob die Antwort zulässig oder nicht zulässig ist. Dieses Feld wird von den zugehörigen HTTP-Antwortattributen für eine Autorisierungsprüfung begleitet.

  • Das Feld ok_response wird verwendet, wenn der Autorisierungsdienst die Anfrage zulässt. Der Dienst kann alle ursprünglichen Anfrage-Header ändern, hinzufügen oder entfernen und HTTP-Antwortheader aktualisieren, die an den Client gesendet werden. Verwenden Sie das Feld raw_value für Header.

  • Das Feld denied_response wird verwendet, wenn der Autorisierungsdienst die Anfrage ablehnt. Der Dienst kann HTTP-Antwortheader aktualisieren, die an den Client gesendet werden.

  Wenn der Erweiterungsdienst über die Nachricht CheckResponse einen unzulässigen Headernamen oder -wert zurückgibt, wird die Anfrage mit dem Statuscode 500 Internal Error abgelehnt. Informationen zu unzulässigen Headern finden Sie unter Einschränkungen bei der Header-Bearbeitung.

• dynamic_metadata: Enthält optionale Metadaten, die von Erweiterungen verwendet werden können, die nach der Autorisierungserweiterung aufgerufen werden, z. B. Standorterweiterungen.

Körperbearbeitungsmodi

Bei Erweiterungen, die die Verarbeitung des Texts unterstützen, können Sie einen der folgenden beiden Sendemodi für die Verarbeitung des Anfrage- und Antworttexts konfigurieren, indem Sie den Wert der Felder request_body_send_mode bzw. response_body_send_mode festlegen.

Der Standardmodus ist STREAMED, der für die meisten Anwendungsfälle empfohlen wird.

Modus	Beschreibung	Unterstützte Ereignisse erforderlich	Unterstützte Erweiterungen
STREAMED	Anrufe werden im Streamingmodus ausgeführt. Diese Standardeinstellung wird auch verwendet, wenn der Modus nicht festgelegt ist. Der Proxy sendet Textkörper-Chunks an den Erweiterungsdienst und erwartet eine einzelne Antwort pro Chunk. Die Erweiterung kann geänderte Chunks zurücksenden, Chunks ohne Änderungen bestätigen oder Chunks löschen. Der Proxy sendet jeweils nur eine begrenzte Menge an Daten. Der Erweiterungsdienst muss Chunks also so schnell wie möglich bestätigen. Der Body-Modus kann zwar nicht dynamisch geändert werden, ein erweiterter Erweiterungsserver kann jedoch dynamisch die zukünftigen HTTP-Ereignisse auswählen, die er empfangen soll. Wenn der Callout-Server die Option ext_proc mode_override bei einer Header-Anfrage zurückgibt, kann er zukünftige Header-, Text- oder Trailer-Ereignisse aktivieren oder deaktivieren.	Muss REQUEST_BODY für Anfragen oder RESPONSE_BODY für Antworten enthalten.	Traffic-Erweiterungen (sowohl für Anfragen als auch für Antworten).
FULL_DUPLEX_STREAMED	Anrufe werden im Vollduplexmodus ausgeführt. Der Proxy sendet Chunks, sobald sie eingehen, und puffert sie nicht. Da es keine Pufferung gibt, reagiert der Proxy weniger empfindlich auf die Latenz der Erweiterung. Der Proxy kann beliebig viele Antwortblöcke empfangen. Antwort-Chunks sind nicht mit den Chunks verbunden, die der Proxy sendet. Nachfolgende Chunks werden zur Verarbeitung gesendet, sobald sie am Proxy eintreffen, ohne dass auf die vollständige Verarbeitung der vorherigen Chunks und Ereignisse gewartet wird. Die Erweiterung kann den Inhalt des Textbereichs beliebig puffern, ändern und neu aufteilen. Wenn die Erweiterung den Inhalt des Texts nicht zurücksendet, erhält die nächste Erweiterung in der Kette einen leeren Text. Die Option ext_proc mode_override ist nicht anwendbar und der Modus kann nicht dynamisch geändert werden. Warnung:Der Proxy wird bis zum ersten verarbeiteten Chunk von Body-Daten geöffnet. Das bedeutet, dass „Fail-Open“ alle Probleme im Zusammenhang mit der Verbindung zur Erweiterung oder der Verarbeitung von Headern behandelt. Fehler nach diesem Punkt werden jedoch als „Fail-Closed“ behandelt und an den Endnutzer weitergegeben.	Muss REQUEST_BODY und REQUEST_TRAILERS für Anfragen oder RESPONSE_BODY und RESPONSE_TRAILERS für Antworten enthalten.	Traffic-Erweiterungen (sowohl für Anfragen als auch für Antworten). Routenerweiterungen (für Anfragen)

Unterstützte Back-Ends für von Nutzern verwaltete Callout-Back-End-Dienste

Sie können von Nutzern verwaltete Zusatzinformationen in einem Back-End-Dienst hosten, der eines der folgenden Back-End-Typen verwendet, auf denen Envoy-gRPC-Dienste ausgeführt werden:

• Alle Backends in verwalteten und nicht verwalteten Instanzgruppen
• Alle zonalen NEGs
• Alle Hybrid-Konnektivitäts-NEGs
• Private Service Connect-NEGs, die auf VPC-Dienste verweisen
• Serverlose NEGs, die auf Cloud Run-Dienste verweisen

Hinweis :Wenn Sie die Erweiterung in Cloud Run hosten, muss der Cloud Run-Dienst auf einem gRPC-Port im Klartextmodus lauschen. Der Cloud Run-Dienst muss für die Annahme von HTTP/2-Traffic konfiguriert sein und nicht authentifizierten Zugriff zulassen.

Empfohlene Optimierungen für Erweiterungen mit Zusatzinformationen

Durch die Einbindung einer Erweiterung in den Verarbeitungspfad für das Load-Balancing entsteht zusätzliche Latenz für Anfragen und Antworten. Jeder Datentyp, der vom Erweiterungsdienst verarbeitet wird, einschließlich Anfrageheadern, Anfragetext, Antwortheadern und Antworttext, je nach Bedarf, führt zu einer zusätzlichen Latenz.

Mit den folgenden Optimierungen können Sie die Latenz minimieren:

• Stellen Sie Callouts in denselben Zonen wie den regulären Ziel-Backend-Dienst für den Load-Balancer bereit. Wenn Sie einen regionenübergreifenden internen Application Load Balancer verwenden, platzieren Sie die Back-Ends des Erweiterungsdienstes in derselben Region wie die Proxy-only-Subnetze des Load Balancers.
• Wenn Sie einen globalen externen Application Load Balancer verwenden, platzieren Sie die Callout-Dienst-Back-Ends in den geografischen Regionen, in denen sich die Ziel-VMs, GKE-Arbeitslasten und Cloud Run Functions des regulären Load Balancers befinden.
• Konfigurieren Sie die Erweiterung nach Möglichkeit so, dass nur die Daten verarbeitet werden, die Sie benötigen. Wenn Sie beispielsweise nur Anfrageheader für Routen- und Traffic-Erweiterungen ändern möchten, setzen Sie das Feld supported_events in der Erweiterung auf REQUEST_HEADERS.

Beschränkungen

In diesem Abschnitt werden einige Einschränkungen für Callouts aufgeführt.

Einschränkungen bei der Header-Bearbeitung

Einige Header können nicht geändert werden. Für die Headerbearbeitung gelten die folgenden Einschränkungen:

• Die Bearbeitung von Headern wird für die folgenden Header nicht unterstützt:

  • X-user-IP
  • CDN-Loop
  • Header, die mit X-Forwarded, X-Google, X-GFE oder X-Amz- beginnen
  • connection
  • keep-alive
  • transfer-encoding, te
  • upgrade
  • proxy-connection, proxy-authenticate, proxy-authorization
  • trailers

  Bei Traffic- und Autorisierungserweiterungen wird die Header-Manipulation auch für die folgenden Header nicht unterstützt: :method, :authority, :scheme oder Host-Header.

• Wenn ein gRPC-Server Header-Werte in HeaderMutation angibt, ignoriert der Load Balancer das Feld value.

Einschränkungen bei der Verarbeitung von Körperdaten

Die folgenden Einschränkungen gelten für HTTP/1.1-Clients und ‑Back-Ends in Bezug auf den Nachrichtentext. Sie gelten für ext_proc, aber nicht für ext_authz.

• Wenn Sie entweder REQUEST_BODY oder RESPONSE_BODY für eine Erweiterung konfigurieren und der Load Balancer eine entsprechende Anfrage empfängt, entfernt er den Content-Length-Header aus der Antwort und wechselt zur Chunked-Body-Codierung.

• Während ein Nachrichtentext an den ext_proc-Server gestreamt wird, sendet der Load Balancer am Ende möglicherweise eine nachfolgende ProcessingRequest-Nachricht mit einem leeren Textkörper und end_stream auf true, um anzugeben, dass der Stream beendet wurde.

Sonstige Einschränkungen

Die folgenden Einschränkungen gelten für gRPC-Antwortnachrichten:

• Die maximale Größe einer Antwortnachricht beträgt 128 KB. Wenn eine empfangene Nachricht dieses Limit überschreitet, wird der Stream mit dem Fehler RESOURCE_EXHAUSTED geschlossen.

• Für den Callout-Backend-Dienst können keine Cloud Armor-, IAP- oder Cloud CDN-Richtlinien verwendet werden.

• Der Callout-Backend-Dienst muss HTTP/2 als Protokoll verwenden.

• Bei Autorisierungserweiterungen leitet der Load-Balancer keinen Anfragetext an den Callout-Backend-Dienst weiter.

• Bei Routenerweiterungen kann der Backend-Dienst für Zusatzinformationen den Verarbeitungsmodus des ext_proc-Streams nicht überschreiben.

Nächste Schritte

• Vom Nutzer verwalteten Callout-Backend-Dienst konfigurieren

  Ein Callout-Backend-Dienst ist eine Voraussetzung für die Konfiguration von Routen-, Autorisierungs- und nutzerverwalteten Traffic-Erweiterungen mithilfe von Callouts.

• Autorisierungserweiterung konfigurieren

• Routenerweiterung konfigurieren

• Traffic-Erweiterung konfigurieren

• Erweiterung für den Aufruf eines Google-Dienstes konfigurieren