La mayor parte de lo que la gente configura día a día en Envoy, manipulación de encabezados, registro de acceso, reintentos, autorización externa, ocurre dentro de un filtro de red concreto: el HTTP Connection Manager. Esta guía cubre qué hace, cómo está estructurada su propia cadena de filtros y las formas de extenderlo con lógica que no viene incorporada.

HCM: de bytes a HTTP

La cadena de filtros de un listener empieza a nivel de red, operando sobre un flujo de bytes en bruto, sin ningún concepto todavía de “una petición”. El HTTP Connection Manager (HCM) es el filtro de red que cambia eso: convierte el flujo de bytes en peticiones, encabezados, cuerpos y trailers HTTP y, a partir de ese punto, todo lo que venga después en la cadena puede trabajar con semántica HTTP en lugar de bytes en bruto.

Aquí es también donde viven las funciones a nivel de petición: registro de acceso, manipulación de peticiones y respuestas y, de forma crucial, la cadena anidada propia del HCM de filtros HTTP, que es un concepto distinto de la cadena de filtros a nivel de red dentro de la que se sitúa.

La cadena de filtros HTTP

Dentro del HCM, los filtros HTTP se ejecutan en un orden definido contra cada petición HTTP: manejo de CORS, rate limiting, autorización externa (una llamada a otro servicio para decidir si se permite una petición), scripting en Lua, módulos de WebAssembly (Wasm) y más. El último filtro de la cadena suele ser un filtro terminal, casi siempre el filtro router, cuyo trabajo es entregar la petición a la coincidencia de rutas y, desde ahí, a un cluster.

El orden importa. Un filtro de rate limiting colocado antes de un filtro de autenticación se comporta de forma distinta que uno colocado después, y la configuración de Envoy para una cadena de filtros es explícita sobre dónde se sitúa cada filtro respecto a los demás, no solo sobre qué filtros están presentes.

Extender Envoy: tus opciones

Cuando ninguno de los filtros incorporados de Envoy hace lo que necesitas, hay varias formas de añadir lógica personalizada, cada una con un costo y un alcance distintos:

• Filtros nativos en C++, compilados directamente en un build personalizado de Envoy. Es la opción más capaz y la más laboriosa: implica mantener tu propio build de Envoy en lugar de consumir uno de upstream. La distribución de Envoy de Istio toma este camino para parte de su comportamiento incorporado.
• Procesamiento externo (ext_proc), donde Envoy llama a un servicio separado a mitad de la petición, ese servicio hace el procesamiento que necesite y devuelve el control a la cadena de filtros. Esto mantiene la lógica personalizada completamente fuera del proceso de Envoy, a costa de un salto de red por petición.
• Scripting en Lua, donde un filtro Lua ejecuta un script embebido contra la petición y/o la respuesta. Rápido de escribir e iterar, sin reconstrucción ni servicio aparte, a costa de limitarte a lo que exponen Lua y la API Lua de Envoy.
• WebAssembly (Wasm), donde compilas un filtro a un módulo .wasm en el lenguaje que elijas, y Envoy lo carga y lo ejecuta como parte de la cadena. Es el mecanismo de extensión más orientado a distribuir y reutilizar un filtro como un artefacto portable, en lugar de un script o un build personalizado.

Cuál encaja depende de cuánto control necesitas frente a cuánta carga operativa estás dispuesto a asumir: un script Lua suele ser la forma más rápida de probar algo, un módulo Wasm es la forma más portable de distribuirlo una vez que sabes que funciona, y un build personalizado en C++ o un servicio externo es lo que queda cuando ninguno de los dos puede hacer lo que necesitas.

Qué necesita realmente un filtro para configurarse

Sea cual sea el mecanismo de extensión que uses, configurar un filtro HTTP siempre se reduce a tres cosas:

1. El nombre del filtro, un identificador estable.
2. Su type URL, que le dice al sistema de configuración de Envoy exactamente qué tipo de filtro es y qué forma tiene su configuración.
3. La configuración específica del filtro en sí, los campos que ese filtro concreto acepta realmente.

La página de documentación de Envoy de cada filtro lista su type URL y sus campos de configuración, aunque la documentación de un filtro dado suele estar repartida en varias páginas de referencia enlazadas en lugar de estar en un solo lugar; encontrar la sintaxis exacta de un campo concreto con frecuencia implica seguir una cadena de enlaces en lugar de leer de arriba abajo. Buscar el type URL de un filtro en alojamientos públicos de código es un atajo práctico una vez que lo conoces: para cualquier cosa razonablemente común, alguien normalmente ya ha publicado una configuración que funciona y desde la que puedes empezar, en lugar de armar una solo a partir de la documentación de referencia.

Dónde aparece esto si usas un service mesh

Si Envoy se ejecuta como sidecar bajo Istio o una malla similar, rara vez escribes configuración de filtros HTTP en bruto a mano para los casos comunes: las propias APIs de la malla (reglas de enrutamiento, políticas de seguridad) la generan por ti. Pero para todo lo que las APIs de alto nivel de la malla no cubren, y siempre hay algo que no cubren, acabas configurando un filtro HTTP directamente a través de la vía de escape de más bajo nivel que ofrezca la malla. La siguiente guía de esta serie cubre exactamente eso, usando como ejemplo el recurso EnvoyFilter de Istio.