Visão geral dos plug-ins

Nesta página, você encontra informações gerais sobre a integração de plug-ins com balanceadores de carga de aplicativo do Cloud Load Balancing e Media CDN.

Esse recurso está em pré-lançamento para a Media CDN.

Os plug-ins são criados usando o formato WebAssembly (Wasm) e APIs Proxy-Wasm.

  • O Wasm é um formato de instrução binária aberto e padronizado que permite que um host carregue e execute módulos Wasm com código fornecido pelo cliente. O Wasm tem vários benefícios para executar o código do cliente, incluindo isolamento para segurança, suporte a várias linguagens, portabilidade, suporte amplo e crescente no setor e melhor desempenho em relação a outras opções baseadas em VM, como JavaScript.

  • O Proxy-Wasm é um projeto de código aberto iniciado pelo Google. Ele define APIs que permitem personalizar o comportamento de proxies de rede implementando callbacks a serem executados durante o processamento de solicitações e respostas HTTP.

Como os plug-ins funcionam

É possível usar as extensões de serviço com balanceadores de carga de aplicativo e Media CDN da seguinte maneira:

  1. Prepare o código do plug-in da seguinte maneira:

    1. Crie um código personalizado usando um dos SDKs do Proxy-Wasm:

    2. Compile seu código em um módulo Wasm.

    3. Faça upload do código do plug-in compilado para um repositório do Artifact Registry.

  2. Crie um plug-in que contenha o código do plug-in enviado.

  3. Configure o plug-in nas extensões do Cloud Load Balancing ou nas extensões do Media CDN.

Recursos de plug-in

As extensões de serviço ajudam a criar os seguintes recursos principais que ajudam a adicionar código personalizado no caminho de processamento:

  • Plug-ins, que contêm o código personalizado que você quer implantar.

  • Versões do plug-in, que são versões do seu módulo Wasm. Você pode indicar qual versão do módulo Wasm um plug-in vai usar como principal (ativa).

Limitações

Esta seção lista algumas limitações dos plug-ins.

Limitações nos recursos

Os plug-ins são estritamente limitados em relação à quantidade de recursos que podem usar:

  • Um plug-in pode usar até 1 ms de vCPU normalizada por invocação. Um milissegundo de CPU depende da plataforma, mas a plataforma normalizada é aproximadamente igual a um processador com uma velocidade de clock de 4 GHz. Uma invocação é uma fase de execução faturada de forma independente, que pode ser cabeçalhos de solicitação, corpo da solicitação, cabeçalhos de resposta ou corpo da resposta.

  • Um plug-in pode usar até 16 MiB de memória por instância de VM. Uma instância precisa ser capaz de atender até 1.000 solicitações simultâneas, o que significa que um plug-in pode armazenar até 16 KiB de memória por stream. O uso total de memória inclui estado global e alocações de pilha.

Use o testador de plug-in para comparar as características de CPU e memória de um plug-in.

Limitações das APIs

  • Os plug-ins podem usar um subconjunto da ABI Proxy-Wasm. Os plug-ins não são compatíveis com timers, métricas personalizadas, dados compartilhados, filas compartilhadas ou chamadas de rede de saída.

  • Não há suporte para eventos de trailer HTTP.

Limitações com a manipulação de cabeçalhos

  • O tamanho máximo de qualquer mutação (cabeçalhos ou partes do corpo) é de 128 KiB.

  • Os plug-ins não podem substituir o modo de processamento do stream ext_proc.

  • A manipulação de cabeçalhos por plug-ins não é compatível com alguns cabeçalhos. O processador ignora qualquer modificação nesses cabeçalhos e continua processando a solicitação.

    Para plug-ins da CDN de mídia, os seguintes recursos não são compatíveis:

    • Cabeçalhos: CDN-Loop, connection, keep-alive, proxy-authenticate, proxy-authorization, proxy-connection, te, trailers, transfer-encoding, upgrade ou X-user-IP.
    • Cabeçalhos que começam com: x-forwarded, x-goog-,x-google, x-gfe ou x-amz-.

    Para plug-ins do Cloud Load Balancing, o seguinte não é compatível:

    • Cabeçalhos: 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 ou x-user-ip.

      Além disso, para LbTrafficExtension, estes cabeçalhos também não são aceitos: method, authority, scheme ou cabeçalhos de host.

    • Cabeçalhos que começam com: sec-gfe-, sec-google-, x-amz-, x-forwarded-, x-gfe-, x-goog-, x-google- ou x-gproxy-.

Limitações com clientes e back-ends HTTP/1.1

Ao configurar REQUEST_BODY ou RESPONSE_BODY para uma extensão, se o balanceador de carga receber uma solicitação correspondente, ele vai remover o cabeçalho Content-Length da resposta e mudar para codificação de corpo em partes.

A seguir