Envoy Proxy es un proxy de borde y de servicio de código abierto y alto rendimiento, diseñado para aplicaciones nativas de la nube, que actúa como un plano de datos universal para arquitecturas de microservicios. Abstrae las complejidades de la red, proporcionando capacidades avanzadas de gestión de tráfico, observabilidad y seguridad esenciales para sistemas distribuidos.
Envoy funciona como un proxy transparente para todo el tráfico de red entre servicios, permitiendo a los desarrolladores y operadores centrarse en la lógica de la aplicación en lugar de en las preocupaciones de la red. Su arquitectura está construida para despliegues modernos de microservicios, ofreciendo características que los proxies tradicionales a menudo carecen o implementan de manera menos eficiente.
Principios Arquitectónicos Fundamentales
El diseño de Envoy prioriza el rendimiento, la extensibilidad y la configuración dinámica. Opera como un servidor de un solo proceso y múltiples hilos, aprovechando la E/S basada en eventos para manejar un alto volumen de conexiones y solicitudes concurrentes de manera eficiente.
Arquitectura de Filtros L3/L4
Envoy emplea una arquitectura de cadena de filtros conectables tanto en las capas de red (L3/L4) como de aplicación (L7). Esto permite un procesamiento altamente personalizable del tráfico de red.
* Filtros de Red: Operan sobre flujos de bytes sin procesar. Ejemplos incluyen proxy TCP, terminación TLS y limitación de velocidad a nivel de conexión.
* Filtros HTTP: Operan sobre solicitudes y respuestas HTTP. Ejemplos incluyen compresión Gzip, inyección de ID de solicitud, autenticación JWT y enrutamiento avanzado.
Esta modularidad permite una aplicación sofisticada de políticas y manipulación de tráfico en varias etapas del ciclo de vida de la solicitud.
Características Clave para Microservicios
Soporte HTTP/2 y gRPC
Envoy proporciona soporte de primera clase para HTTP/2 y gRPC, protocolos esenciales en microservicios modernos. Puede conectar clientes HTTP/1.1 a servicios HTTP/2, terminar conexiones HTTP/2 y facilitar el proxying de gRPC, incluyendo características avanzadas como el balanceo de carga y enrutamiento conscientes de gRPC.
Balanceo de Carga Avanzado
Envoy ofrece un conjunto de algoritmos sofisticados de balanceo de carga más allá del simple round-robin:
* Menos Solicitudes (Least Request): Enruta al backend con el menor número de solicitudes activas.
* Hash de Anillo (Ring Hash): Hashing consistente para una mejor utilización de la caché y sesiones pegajosas.
* Maglev (Power of Two Choices): Elige dos hosts aleatorios y selecciona el que tiene menos solicitudes activas, equilibrando la simplicidad con una distribución casi óptima.
* Aleatorio (Random): Para una distribución simple e imparcial.
* Destino Original (Original Destination): Enruta a la IP de destino prevista sin descubrimiento de servicio.
También soporta reintentos automáticos, disyuntores (circuit breaking), detección de anomalías (outlier detection) y comprobación de salud (health checking) para asegurar que el tráfico solo se envíe a instancias saludables, mejorando la resiliencia.
Configuración Dinámica (API xDS)
Una piedra angular del diseño nativo de la nube de Envoy son sus capacidades de configuración dinámica a través de la API xDS (Discovery Service). En lugar de archivos de configuración estáticos, Envoy puede recibir actualizaciones para varios recursos dinámicamente:
* Servicio de Descubrimiento de Listeners (LDS): Listeners (puertos a los que se enlaza Envoy).
* Servicio de Descubrimiento de Rutas (RDS): Reglas de enrutamiento HTTP.
* Servicio de Descubrimiento de Clústeres (CDS): Clústeres ascendentes (grupos de servicios backend).
* Servicio de Descubrimiento de Endpoints (EDS): Endpoints (instancias individuales) dentro de los clústeres.
* Servicio de Descubrimiento de Secretos (SDS): Certificados TLS y claves privadas.
* Servicio de Descubrimiento en Tiempo de Ejecución (RTDS): Valores de configuración dinámica en tiempo de ejecución.
Esto permite cambios de configuración sin tiempo de inactividad, posibilitando el despliegue continuo y la integración con planos de control de service mesh (por ejemplo, Istio, App Mesh) que gestionan estas configuraciones.
Observabilidad
Envoy está diseñado con la observabilidad como un ciudadano de primera clase, proporcionando información profunda sobre el tráfico de red:
* Estadísticas Detalladas: Emite un gran número de estadísticas (más de 100 por clúster ascendente) que cubren conexiones, solicitudes, errores, latencia y más, que pueden ser recolectadas por Prometheus o sistemas similares.
* Trazado Distribuido: Soporta sistemas de trazado populares como Jaeger, Zipkin y AWS X-Ray, propagando contextos de trazado (por ejemplo, B3, W3C Trace Context) y generando spans para cada salto.
* Registro de Acceso (Access Logging): Registros de acceso completos y personalizables que detallan cada solicitud, incluyendo encabezados, códigos de respuesta e información de tiempo.
Estas características son cruciales para la depuración, el análisis de rendimiento y la monitorización de microservicios distribuidos.
Características de Seguridad
Envoy proporciona robustas características de seguridad, a menudo descargando estas preocupaciones del código de la aplicación:
* Terminación y Origen TLS: Maneja el cifrado/descifrado TLS, permitiendo que los servicios se comuniquen internamente en texto plano mientras mantienen una comunicación externa segura.
* TLS Mutuo (mTLS): Facilita la comunicación segura y autenticada entre servicios dentro de una malla mediante la validación de certificados de cliente.
* Limitación de Velocidad (Rate Limiting): Aplica límites de velocidad de solicitud para proteger los servicios de sobrecarga o abuso.
* Autenticación y Autorización: Se integra con servicios de autorización externos (por ejemplo, OPA) a través de su filtro de Autorización Externa, permitiendo un control de acceso granular.
El Papel de Envoy en las Arquitecturas de Microservicios
Proxy Sidecar
El patrón de despliegue más común para Envoy en un entorno de microservicios es como un proxy sidecar. En este modelo, cada instancia de servicio ejecuta un proxy Envoy junto a ella, típicamente dentro del mismo pod en Kubernetes. Todo el tráfico de red entrante y saliente para el servicio es interceptado y gestionado de forma transparente por el sidecar.
Este enfoque ofrece varios beneficios:
* Abstracción de Red: Los desarrolladores de aplicaciones escriben servicios que se comunican con localhost, y el sidecar de Envoy maneja el enrutamiento, los reintentos y otras preocupaciones de la red.
* Soporte Políglota: Permite políticas y características de red consistentes en servicios escritos en diferentes lenguajes y frameworks.
* Aislamiento: Las preocupaciones de la red están aisladas de la lógica de negocio, simplificando el desarrollo y el despliegue.
Plano de Datos de Service Mesh
Envoy sirve como el plano de datos de facto para muchas implementaciones populares de service mesh (por ejemplo, Istio, Linkerd, AWS App Mesh). En un service mesh, un plano de control gestiona y configura una flota de proxies Envoy (el plano de datos). El plano de control utiliza la API xDS para actualizar dinámicamente la configuración de todos los Envoys en la malla, aplicando políticas de tráfico, seguridad y observabilidad en todo el ecosistema de microservicios.
Proxy de Borde / API Gateway
Envoy también puede desplegarse en el borde de una red como un API gateway o proxy inverso. En este rol, maneja el tráfico de entrada, realiza autenticación, limitación de velocidad, terminación TLS y enruta las solicitudes a los servicios backend apropiados dentro de la arquitectura de microservicios. Sus capacidades avanzadas de enrutamiento L7 lo hacen adecuado para requisitos complejos de enrutamiento de borde.
Ejemplo de Configuración
Una configuración básica de Envoy define listeners, cadenas de filtros y clústeres. Este ejemplo muestra un listener en el puerto 10000 que proxy solicitudes HTTP a un clúster de servicio ascendente llamado web_service.
static_resources:
listeners:
- name: listener_0
address:
socket_address:
protocol: TCP
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
codec_type: AUTO
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match:
prefix: "/"
route:
cluster: web_service
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
clusters:
- name: web_service
connect_timeout: 0.25s
type: LOGICAL_DNS
# Comment out the following line to test on v6.
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: web_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: webserver.example.com # Replace with your actual service hostname/IP
port_value: 80
Comparación con Otros Proxies
| Característica | Envoy Proxy | Nginx | HAProxy |
|---|---|---|---|
| Caso de Uso Principal | Service Mesh, Sidecar, API Gateway, Borde | Servidor Web, Proxy Inverso, Balanceador de Carga | Balanceador de Carga L4 de Alto Rendimiento, L7 |
| Arquitectura | Basada en eventos, C++, filtros altamente modulares | Basada en eventos, C, basada en módulos | Basada en eventos, C, altamente optimizada |
| Configuración Dinámica | API xDS completa para todos los recursos | Recarga la configuración (disruptiva) o API comercial | API en tiempo de ejecución para cambios limitados, recarga de configuración |
| HTTP/2 y gRPC | Soporte de primera clase, características avanzadas | Buen soporte | Buen soporte |
| Observabilidad | Métricas extensas, trazado, registros de acceso | Métricas básicas, trazado limitado | Estadísticas detalladas, registro básico |
| Balanceo de Carga | L7 avanzado (hash consistente, Maglev), L4 | L7 básico (round-robin, menos conexiones), L4 | L4 avanzado, algo de L7 (menos conexiones, origen) |
| Descubrimiento de Servicio | Integrado con xDS, DNS, estático | DNS, estático, algunas integraciones comerciales | DNS, estático, algunas integraciones comerciales |
| Disyuntores (Circuit Breaking) | Sí | No (requiere lógica externa) | Sí |
| Detección de Anomalías (Outlier Detection) | Sí | No (requiere lógica externa) | No (requiere lógica externa) |
| Rol en Service Mesh | Plano de Datos (elección principal) | No diseñado para este rol | No diseñado para este rol |
| Extensibilidad | Filtros C++, extensiones WASM | Scripting Lua, módulos C | Scripting Lua, módulos C |
Consideraciones Prácticas
Ajuste de Rendimiento
Envoy es altamente eficiente de fábrica, pero despliegues específicos pueden beneficiarse de ajustes. Las áreas clave incluyen:
* Configuración de Hilos: Ajustar el número de hilos de trabajo para que coincida con los núcleos de la CPU.
* Gestión de Búferes: Optimizar los tamaños de los búferes de lectura/escritura.
* Dimensionamiento del Pool de Conexiones: Configurar el número máximo de conexiones y solicitudes por conexión a los clústeres ascendentes.
Consumo de Recursos
Aunque eficiente, ejecutar un sidecar de Envoy para cada instancia de servicio aumenta el consumo general de recursos (CPU, memoria). Este compromiso es a menudo aceptable por los beneficios operativos que proporciona un service mesh. Una monitorización cuidadosa del uso de recursos es crucial en despliegues grandes.
Depuración
Envoy proporciona una interfaz de administración (típicamente en el puerto 15000) que ofrece valiosos puntos finales de depuración:
* /stats: Estadísticas actuales.
* /config_dump: Vuelca la configuración activa actual.
* /clusters: Estado de los clústeres ascendentes.
* /hot_restart: Inicia un reinicio en caliente elegante.
Estos puntos finales son fundamentales para solucionar problemas de configuración, monitorear la salud y comprender el flujo de tráfico.