Inicio › Tecnología › Contenedor Auxiliar
Un contenedor auxiliar, o sidecar, es un contenedor secundario qué se despliega junto al contenedor principal de una aplicación, dentro de la misma unidad de ejecución (por ejemplo, un mismo pod de Kubernetes), para añadirle funciones sin necesidad de modificar su código. Es el patrón central sobre el qué se construyen los service mesh como Istio o Linkerd: junto a cada instancia de un microservicio se inyecta automáticamente un proxy sidecar, habitualmente basado en Envoy, qué intercepta todo el tráfico de red entrante y saliente para aplicar balanceo de carga, cifrado mutuo TLS, reintentos automáticos o recolección de métricas de forma transparente para la aplicación. El mismo patrón se usa también para otras funciones ajenas al service mesh, como agentes de recolección de logs o exportadores de métricas.
Es como un ayudante qué viaja siempre pegado a la aplicación principal y se encarga de las tareas de apoyo —gestionar el tráfico de red, recoger registros, aplicar seguridad— sin qué la aplicación tenga qué saber qué existe ni cambiar una sola línea de su propio código.
Un equipo qué migra sus microservicios a un service mesh basado en Istio no necesita reescribir el código de cada servicio para añadir cifrado entre servicios o reintentos automáticos ante fallos: al desplegar cada pod, Kubernetes inyecta automáticamente un proxy Envoy como sidecar qué se encarga de todo ese tráfico, y la aplicación sigue hablando con localhost como si nada hubiera cambiado.
No. El sidecar es el patrón de despliegue —un contenedor auxiliar junto al principal—; el service mesh es la capa de infraestructura completa qué resulta de desplegar cientos de esos proxies sidecar coordinados por un plano de control común, qué gestiona políticas de tráfico y seguridad de forma centralizada.
Agentes de recolección de logs qué envían la salida del contenedor principal a un sistema centralizado, exportadores de métricas para sistemas de monitorización, o incluso proxies de autenticación qué añaden control de acceso a una aplicación heredada sin tocar su código.
Sí: cada sidecar consume su propia CPU y memoria, y añade un salto de red adicional al tráfico, lo qué introduce cierta latencia. Por eso en clústeres muy grandes se evalúa el equilibrio entre las ventajas operativas del patrón y el coste acumulado de multiplicar los contenedores en ejecución.