Plugins overview

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page provides overview information about the integration of plugins with Cloud Load Balancing Application Load Balancers and Media CDN.

Plugins are built using WebAssembly (Wasm) format and use Proxy-Wasm APIs.

• Wasm is an open and standardized binary instruction format that enables a host to load and run Wasm modules with customer-provided code. Wasm has a number of benefits for executing customer code, including sandboxing for security, support for multiple languages, portability, broad and growing support within the industry, and improved performance relative to other VM-based options such as JavaScript.

• Proxy-Wasm is an open source project started by Google. It defines APIs that let you customize the behavior of network proxies by implementing callbacks to be executed during HTTP request and response processing.

How plugins work

You can use Service Extensions with Application Load Balancers and Media CDN as follows:

1. Create custom code by using one of the Proxy-Wasm SDKs:

   • Rust

   • C++

   Note: The Proxy-Wasm Go SDK is not supported by Google. If you want to use it, ensure that you use a robust memory manager, such as nottinygc.

2. Compile your code into a Wasm module.

3. Build a Docker container image that contains your Wasm module.

4. Publish your container image to an Artifact Registry repository. Specify image tags or digests, as required.

5. Create a plugin that contains the uploaded Wasm module.

6. To run these plugins, configure Cloud Load Balancing extensions or Media CDN extensions.

Plugin resources

Service Extensions helps you create the following key resources that help you add custom code in the processing path:

• Plugins, which contain the custom code that you want to deploy.

• Plugin versions, which are versions of a container image. You can indicate which version a plugin is to use as its main (active) one.

Limitations

This section lists some limitations with plugins.

Limitations on resources

Plugins can use a maximum of 16 MiB of memory per VM and 1 ms of vCPU time at runtime.

Limitations on APIs

Plugins can use a subset of the Proxy-Wasm ABI. Plugins don't support timers, custom metrics, shared data, shared queues, or outbound network calls.

Limitations with header manipulation

• The maximum size of any mutation (headers or body chunks) is 128 KiB.

• You cannot change some headers. Header manipulation is not supported for the following headers:

  • X-user-IP
  • CDN-Loop
  • Headers starting with X-Forwarded, X-Google, X-GFE, or X-Amz-
  • connection
  • keep-alive
  • transfer-encoding, te
  • upgrade
  • proxy-connection, proxy-authenticate, proxy-authorization
  • trailers

  For plugins used in an LbTrafficExtension resource, header manipulation is also not supported for these: :method, :authority, :scheme, or host headers.

Limitations with HTTP/1.1 clients and backends

When you configure either REQUEST_BODY or RESPONSE_BODY for an extension, if the load balancer receives a matching request, it removes the Content-Length header from the response and switches to chunked body encoding.

What's next

• Prepare the plugin code
• Create a plugin