El proxy de RenLayer se distribuye como una única imagen de contenedor que puedes desplegar en una de tres topologías. La elección correcta depende de cómo están organizados tus agentes y de cuán estrictas sean tus fronteras de red.
Patrón 1: Sidecar
Cada agente (o pod que aloja un agente) ejecuta su propia instancia de proxy, típicamente en localhost:8080. El agente habla con el proxy local y el proxy sale hacia los proveedores upstream.
Ideal cuando:
- Ejecutas agentes en Kubernetes y ya usas un patrón sidecar.
- Quieres aislamiento de fallos, si un proxy hipa, solo se ve afectado un agente.
- Necesitas política de red por agente (p. ej., solo este pod puede alcanzar
api.openai.com).
Compromisos: más instancias de proxy que operar, uso de recursos global ligeramente mayor.
Patrón 2: Gateway
Una pequeña flota de instancias de proxy detrás de un balanceador de carga (o service mesh) sirve a todos los agentes de una región. Los agentes llaman a la URL compartida del proxy.
Ideal cuando:
- Tienes muchos agentes pequeños y quieres centralizar el punto de salida.
- Quieres un único punto de control para las ACLs de red hacia los proveedores upstream.
- Quieres compartir pools de conexión y sesiones TLS hacia el upstream.
Compromisos: un fallo a nivel del gateway afecta a todos los agentes.
Patrón 3: Standalone
Una única instancia de proxy para un entorno pequeño, típico de desarrollo, demos y despliegues de producción de un solo nodo.
Ideal cuando:
- Estás evaluando RenLayer en un portátil o cluster de pruebas.
- Ejecutas una flota pequeña de agentes y todavía no necesitas escalar horizontalmente.
Configuración
El proxy se configura por completo mediante variables de entorno. Las más habituales:
RENLAYER_DATABASE_URL: cadena de conexión a la base de datos (compartida con la API de plataforma).RENLAYER_API_URL: URL base de la API de plataforma.RENLAYER_LISTEN_ADDR: dirección de escucha (p. ej.0.0.0.0:8080).RENLAYER_DEFAULT_UPSTREAM: URL upstream de reserva cuando el agente no la sobrescribe.RENLAYER_LOG_LEVEL: uno deerror,warn,info,debug,trace.
Los upstreams por agente (p. ej., un agente va a OpenAI, otro a un servidor de modelos privado) se configuran en el registro del agente en la consola, no requiere reinicio del proxy.
Salud y disponibilidad
El proxy expone /healthz (liveness) y /readyz (readiness, verifica conectividad con la base de datos). Úsalos para probes de Kubernetes y health checks del balanceador.
Dimensionamiento
Una instancia típica de proxy maneja cómodamente el tráfico de agentes en producción sobre un contenedor modesto, con evaluación de políticas y DLP habilitados. La guía detallada de dimensionamiento está disponible bajo NDA.
A dónde ir después
- Cómo funciona: flujo de la petición.
- Políticas: qué se ejecuta en línea.
- Límites de tasa: protegiendo tu presupuesto upstream.