El proxy de RenLayer es un único binario (y 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 Postgres (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 vLLM 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 2,000–4,000 peticiones por segundo en un contenedor modesto de 2 vCPU con evaluación de políticas y DLP basado en patrones habilitados. Las llamadas a modelos grandes están limitadas por la latencia del upstream, no por el proxy.
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.