Sidecar de malla de servicios
El proxy (normalmente Envoy) que se inyecta como sidecar junto a cada servicio de una malla de servicios y captura todo su tráfico de red. Al situarse entre los servicios aporta mTLS, gestión de tráfico, reintentos y observabilidad — sin tocar el código de la aplicación.
Mecánica: la malla (Istio, Linkerd) inyecta automáticamente un proxy sidecar en cada pod; todo el tráfico entrante y saliente pasa por él. Los proxies (el data plane) se controlan de forma centralizada desde un control plane. Lo que ofrecen "gratis": mTLS (cifrado mutuo automático entre servicios), gestión de tráfico (canary, enrutado ponderado, inyección de fallos), resiliencia (reintentos, timeouts, circuit breaking) y observabilidad (métricas, trazas y logs de todo el tráfico servicio a servicio). Contrapartida: un proxy por pod supone sobrecarga de recursos y latencia, además de complejidad operativa → por eso crecen las mallas "sin sidecar" (Istio Ambient, Cilium), que trasladan la función al nodo o a eBPF. El patrón dominante para la comunicación servicio a servicio en clústeres grandes. Relacionado con el contenedor sidecar y las network policy.