Panoramica dei plug-in

Questa pagina fornisce informazioni generali sull'integrazione dei plug-in con i bilanciatori del carico delle applicazioni di Cloud Load Balancing e Media CDN.

Questa funzionalità è in Anteprima per Media CDN.

I plug-in vengono creati utilizzando il formato WebAssembly (Wasm) e utilizzano le API Proxy-Wasm.

  • Wasm è un formato di istruzioni binarie aperto e standardizzato che consente a un host di caricare ed eseguire moduli Wasm con codice fornito dal cliente. Wasm offre una serie di vantaggi per l'esecuzione del codice dei clienti, tra cui il sandboxing per la sicurezza, il supporto di più linguaggi, la portabilità, un supporto ampio e in crescita nel settore e prestazioni migliorate rispetto ad altre opzioni basate su macchine virtuali (VM), come JavaScript.

  • Proxy-Wasm è un progetto open source avviato da Google. Definisce le API che ti consentono di personalizzare il comportamento dei proxy di rete implementando i callback da eseguire durante l'elaborazione delle richieste e delle risposte HTTP.

Come funzionano i plug-in

Puoi utilizzare Service Extensions con i bilanciatori del carico delle applicazioni e Media CDN nel seguente modo:

  1. Prepara il codice del plug-in come segue:

    1. Crea codice personalizzato utilizzando uno degli SDK Proxy-Wasm:

    2. Compila il codice in un modulo Wasm.

    3. Carica il codice del plug-in compilato in un repository Artifact Registry.

  2. Crea un plug-in che contenga il codice del plug-in caricato.

  3. Configura il plug-in nelle estensioni di Cloud Load Balancing o nelle estensioni di Media CDN.

Risorse dei plug-in

Service Extensions ti aiuta a creare le seguenti risorse chiave che ti consentono di aggiungere codice personalizzato nel percorso di elaborazione:

  • Plug-in, che contengono il codice personalizzato di cui vuoi eseguire il deployment.

  • Versioni del plug-in, ovvero le versioni del modulo Wasm. Puoi indicare quale versione del modulo Wasm deve essere utilizzata da un plug-in come versione principale (attiva).

Accedi agli attributi nei plug-in

I plug-in Wasm possono accedere agli attributi inoltrati utilizzando la chiamata ABI proxy_get_property, che fa parte dell'ABI Proxy-Wasm. Il nome della proprietà che puoi recuperare corrisponde al nome dell'attributo.

Puoi accedere alle proprietà come rappresentazione del percorso del nome dell'attributo. Ad esempio, per recuperare request.host, puoi utilizzare una rappresentazione del percorso come {"request", "host"}.

Il seguente esempio concettuale di Rust mostra come accedere agli attributi inoltrati all'interno di un'implementazione HttpContext:

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
}

Limitazioni

Questa sezione elenca alcune limitazioni dei plug-in.

Limitazioni delle risorse

I plug-in sono rigorosamente limitati nel numero di risorse che possono utilizzare:

  • Un plug-in può utilizzare fino a 1 msec di vCPU normalizzata per ogni chiamata. Un millisecondo di CPU dipende dalla piattaforma, ma la piattaforma normalizzata è approssimativamente uguale a un processore con una velocità di clock di 4 GHz. Una chiamata è una fase di esecuzione fatturata in modo indipendente, che può essere costituita da intestazioni della richiesta, corpo della richiesta, intestazioni della risposta o corpo della risposta.

  • Un plug-in può utilizzare fino a 16 MiB di memoria per ogni istanza VM (4 MiB per i plug-in Media CDN).

    • Un'istanza deve essere in grado di gestire fino a 1000 richieste in parallelo, il che significa che un plug-in può contenere fino a 16 KiB di memoria per ogni stream (4 KiB per i plug-in Media CDN). L'utilizzo totale della memoria include le allocazioni dello stato globale e dello stack. I plug-in che superano questo limite vengono terminati.

    • Ti consigliamo di utilizzare C++ e Rust, perché producono plug-in con il footprint della memoria più ridotto. L'SDK Go non è consigliato per Media CDN perché il runtime Go e il garbage collector richiedono un footprint della memoria di base minimo di 2-3 MiB.

Utilizza il tester dei plug-in per eseguire il benchmark delle caratteristiche della CPU e della memoria di un plug-in.

Limitazioni relative alle API

  • I plug-in possono utilizzare un sottoinsieme dell'ABI Proxy-Wasm. I plug-in non supportano timer, metriche personalizzate, dati condivisi, code condivise o chiamate di rete in uscita.

  • Gli eventi trailer HTTP non sono supportati.

Limitazioni relative alla manipolazione delle intestazioni

  • La dimensione massima di qualsiasi mutazione (intestazioni o blocchi del corpo) è 128 KiB.

  • I plug-in non possono eseguire l'override della modalità di elaborazione dello stream ext_proc.

  • La manipolazione delle intestazioni tramite plug-in non è supportata per alcune intestazioni. Il processore ignora eventuali modifiche in queste intestazioni e continua a elaborare la richiesta.

    Per i plug-in Media CDN, non sono supportati i seguenti elementi:

    • Intestazioni: CDN-Loop, connection, keep-alive, proxy-authenticate, proxy-authorization, proxy-connection, te, trailers, transfer-encoding, upgrade o X-user-IP.
    • Intestazioni che iniziano con: x-forwarded, x-goog-,x-google, x-gfe o x-amz-.

    Per i plug-in di Cloud Load Balancing, non sono supportati:

    • Intestazioni: 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 o x-user-ip.

      Inoltre, per LbTrafficExtension, non sono supportate nemmeno queste intestazioni: method, authority, scheme o intestazioni host.

    • Intestazioni che iniziano con: sec-gfe-, sec-google-, x-amz-, x-forwarded-, x-gfe-, x-goog-, x-google- o x-gproxy-.

Limitazioni con client e backend HTTP/1.1

Quando configuri REQUEST_BODY o RESPONSE_BODY per un'estensione, se il bilanciatore del carico riceve una richiesta corrispondente, rimuove l'intestazione Content-Length dalla risposta e passa alla codifica del corpo in blocchi.

Passaggi successivi