Auf dieser Seite finden Sie allgemeine Informationen zur Integration von Plug‑ins in Application Load Balancer von Cloud Load Balancing und Media CDN.
Diese Funktion befindet sich für Media CDN im Vorschaumodus.
Plug‑ins werden im WebAssembly-Format (Wasm) erstellt und verwenden Proxy-Wasm-APIs.
Wasm ist ein offenes und standardisiertes binäres Anweisungsformat, mit dem ein Host Wasm-Module mit vom Kunden bereitgestelltem Code laden und ausführen kann. Wasm bietet eine Reihe von Vorteilen für die Ausführung von Kundencode, darunter Sandboxing für die Sicherheit, Unterstützung für mehrere Sprachen, Portabilität, breite und wachsende Unterstützung in der Branche sowie eine verbesserte Leistung im Vergleich zu anderen VM-basierten Optionen wie JavaScript.
Proxy-Wasm ist ein Open Source-Projekt, das von Google gestartet wurde. Es definiert APIs, mit denen Sie das Verhalten von Netzwerkproxys anpassen können, indem Sie Callbacks implementieren, die während der Verarbeitung von HTTP-Anfragen und ‑Antworten ausgeführt werden.
Funktionsweise von Plug‑ins
Sie können Service Extensions mit Application Load Balancern und Media CDN so verwenden:
Plug‑in mit dem hochgeladenen Plug‑in-Code erstellen.
Plug‑in in Cloud Load Balancing-Erweiterungen oder Media CDN-Erweiterungen konfigurieren.
Plug‑in-Ressourcen
Mit Diensterweiterungen können Sie die folgenden wichtigen Ressourcen erstellen, mit denen Sie benutzerdefinierten Code im Verarbeitungspfad hinzufügen können:
Plug‑ins, die den benutzerdefinierten Code enthalten, den Sie bereitstellen möchten.
Plug‑in-Versionen, die Versionen Ihres Wasm-Moduls sind. Sie können angeben, welche Version Ihres Wasm-Moduls ein Plug‑in als Hauptversion (aktiv) verwenden soll.
Auf Attribute in Plug‑ins zugreifen
Wasm-Plug‑ins können mit dem ABI-Aufruf proxy_get_property, der Teil des Proxy-Wasm-ABI ist, auf weitergeleitete Attribute zugreifen. Der abzurufende Property-Name entspricht dem Attributnamen.
Sie können auf Properties als Pfaddarstellung des Attributnamens zugreifen. Wenn Sie
beispielsweise request.host abrufen möchten, können Sie eine Pfaddarstellung wie
{"request", "host"} verwenden.
Das folgende konzeptionelle Rust-Beispiel zeigt, wie Sie in einer HttpContext-Implementierung auf weitergeleitete Attribute zugreifen:
use proxy_wasm::traits::{HttpContext, RootContext}; use proxy_wasm::types::Action; // ... inside your HttpContext implementation ... fn on_request_headers(&mut self, _num_headers: usize, _end_of_stream: bool) -> Action { if let Some(host) = self.get_property(vec!["request", "host"]) { // host is a Vec, convert to string let host_str = String::from_utf8(host).unwrap_or_default(); log::info!("Request host: {}", host_str); } if let Some(region) = self.get_property(vec!["source", "client_region"]) { let region_str = String::from_utf8(region).unwrap_or_default(); log::info!("Client region: {}", region_str); } Action::Continue }
Beschränkungen
In diesem Abschnitt werden einige Einschränkungen für Plug‑ins aufgeführt.
Ressourceneinschränkungen
Die Verwendung von Ressourcen durch Plug‑ins ist stark eingeschränkt:
Ein Plug‑in kann pro Aufruf bis zu 1 ms normalisierte vCPU verwenden. Eine CPU-Millisekunde ist plattformabhängig, aber die normalisierte Plattform entspricht ungefähr einem Prozessor mit einer Taktgeschwindigkeit von 4 GHz. Ein Aufruf ist eine unabhängig in Rechnung gestellte Phase der Ausführung, die Anfrageheader, Anfragetext, Antwortheader oder Antworttext sein kann.
Ein Plug‑in kann pro VM-Instanz bis zu 16 MiB Arbeitsspeicher verwenden. Eine Instanz muss bis zu 1.000 gleichzeitige Anfragen verarbeiten können. Das bedeutet, dass ein Plug‑in pro Stream bis zu 16 KiB Arbeitsspeicher belegen kann. Die Gesamtspeichernutzung umfasst den globalen Status und die Stackzuweisungen.
Verwenden Sie den Plug‑in-Tester, um die CPU- und Arbeitsspeichereigenschaften eines Plug‑ins zu testen.
Einschränkungen bei APIs
Plug‑ins können eine Teilmenge des Proxy-Wasm-ABI verwenden. Plug‑ins unterstützen keine Timer, benutzerdefinierten Messwerte, weitergegebenen Daten, freigegebenen Warteschlangen oder ausgehenden Netzwerk aufrufe.
HTTP-Trailer-Ereignisse werden nicht unterstützt.
Einschränkungen bei der Headerbearbeitung
Die maximale Größe einer Mutation (Header oder Textblöcke) beträgt 128 KiB.
Plug‑ins können den Verarbeitungsmodus des
ext_proc-Streams nicht überschreiben.Die Headerbearbeitung über Plug‑ins wird für einige Header nicht unterstützt. Der Prozessor ignoriert alle Änderungen an diesen Headern und verarbeitet die Anfrage weiter.
Für Media CDN-Plug‑ins werden die folgenden Elemente nicht unterstützt:
- Header:
CDN-Loop,connection,keep-alive,proxy-authenticate,proxy-authorization,proxy-connection,te,trailers,transfer-encoding,upgrade, oderX-user-IP. - Header, die mit
x-forwarded,x-goog-,x-google,x-gfeoderx-amz-beginnen.
Für Cloud Load Balancing-Plug‑ins werden die folgenden Elemente nicht unterstützt:
Header:
connection,keep-alive,proxy-authenticate,proxy-authorization,proxy-connection,sec-user-ip,te,trailer,transfer-encoding,upgrade,x-dont-count-ads,x-dont-show-ads,x-gr,x-proxyuser-ip, oderx-user-ip.Außerdem werden für
LbTrafficExtensionauch die folgenden Header nicht unterstützt:method,authority,schemeoder Host-Header.Header, die mit
sec-gfe-,sec-google-,x-amz-,x-forwarded-,x-gfe-,x-goog-,x-google-oderx-gproxy-beginnen.
- Header:
Einschränkungen bei HTTP/1.1-Clients und ‑Backends
Wenn Sie entweder REQUEST_BODY oder RESPONSE_BODY für eine Erweiterung konfigurieren und der Load Balancer eine entsprechende Anfrage erhält, entfernt er den Header Content-Length aus der Antwort und wechselt zur Chunked-Body-Codierung.