El modelo de configuración de Envoy no cambia según dónde lo despliegues, pero dónde lo despliegues cambia qué problema resuelve. Esta guía cubre los patrones de despliegue habituales y por qué una propiedad de Envoy, ser lo bastante barato como para ejecutarse como una instancia por aplicación, es lo que hace posible el más interesante de ellos.

Edge proxy: la puerta de entrada a tu red

Desplegado en el edge, Envoy se sitúa entre el mundo exterior y tus servicios internos, aceptando tráfico de ingress de clientes externos y, en la otra dirección, gestionando el tráfico de egress que tus propios servicios envían hacia fuera. Esta es la posición clásica de API gateway o balanceador de carga: una (o un pequeño conjunto redundante de) instancia de Envoy que hace terminación TLS, enrutamiento y rate limiting de todo lo que cruza el límite de la red, en cualquier dirección.

Front proxy: un balanceador de carga interno compartido

Un patrón interno más simple: un único Envoy (o un pequeño clúster de ellos) al que todos los servicios internos envían sus peticiones, y que luego las distribuye al backend correcto. Esto parece un balanceador de carga interno convencional y, funcionalmente, lo es, solo que implementado con el enrutamiento y los health checks de Envoy en lugar de un appliance de balanceo diseñado a propósito.

Sidecar: un Envoy por instancia de servicio

Este es el patrón que distingue a Envoy de la mayoría de los demás proxies: en lugar de una instancia compartida que gestiona el tráfico de muchos servicios, una instancia de Envoy se ejecuta junto a cada instancia de cada servicio, en términos de Kubernetes, como un segundo contenedor en el mismo Pod. El tráfico entrante y saliente de cada servicio fluye por su propia instancia de proxy dedicada en lugar de una compartida.

Dos cosas se derivan directamente de esta cercanía:

• La aplicación deja de necesitar conocer el networking. Los reintentos, timeouts, TLS y la lógica de balanceo de carga salen del código de la aplicación y pasan al proxy que está justo al lado, que es exactamente la separación de responsabilidades que el diseño de Envoy se propuso lograr.
• La resolución de problemas se vuelve más rápida. Cuando Envoy es un componente compartido en algún otro lugar de la red, un problema podría estar en la aplicación, en el proxy o en la ruta de red entre ambos. Cuando Envoy se ejecuta justo al lado de la única instancia de aplicación a la que sirve, esa ambigüedad desaparece en gran parte: si el sidecar reporta una conexión sana con la aplicación pero la petición sigue fallando, el espacio de búsqueda se ha reducido mucho.

Ejecutar un Envoy por instancia solo funciona porque Envoy es deliberadamente ligero; un proxy con una huella pesada por instancia no podría desplegarse con esta densidad sin convertirse en el costo de recursos de ejecutar la aplicación por segunda vez.

Service mesh: sidecars, coordinados

Un service mesh es el patrón sidecar aplicado de forma coherente a toda una aplicación: cada instancia de servicio tiene su propio Envoy, y todos esos proxies se configuran y observan como un sistema coordinado en lugar de como instancias independientes gestionadas individualmente. Aquí es donde las funciones de gestión de tráfico de Envoy, reintentos, circuit breaking, TLS mutuo, enrutamiento fino, se aplican de manera uniforme a todos los servicios de la malla, sin que el código de ningún servicio individual necesite implementarlas.

Configurar a mano cientos de instancias individuales de Envoy no es práctico, y por eso los service meshes existen como su propia capa sobre Envoy en lugar de ser “solo Envoy, desplegado muchas veces”. Istio es el ejemplo más destacado: su plano de datos es específicamente Envoy, con el propio plano de control de Istio, istiod, que genera y envía la configuración de cada sidecar automáticamente a medida que cambian los servicios y las políticas. Si ejecutas kubectl exec en un Pod al que Istio ha inyectado un sidecar y miras sus logs, lo que se está ejecutando es un proceso Envoy real, configurado por Istio y no a mano.

Los patrones mixtos son normales

Las topologías de producción suelen combinar más de uno de estos: Envoy en el edge gestionando ingress y egress de todo el clúster, y sidecars de Envoy gestionando el tráfico entre servicios dentro de él. Nada en Envoy obliga a un único patrón; elegir uno, o una combinación, es cuestión de qué tráfico necesita qué tipo de control, no una limitación del proxy.