Acerca de la capa de agente de GKE

Agent Substrate ejecuta cargas de trabajo basadas en agentes a gran escala en clústeres de Kubernetes. Aborda una ineficiencia de recursos común: los agentes interactivos (como los asistentes personales y los agentes de programación) suelen pasar la mayor parte del tiempo esperando la entrada del usuario o los activadores externos. Mantener estos agentes inactivos en ejecución continua usa CPU y memoria que, de lo contrario, podrían asignarse a cargas de trabajo activas.

Agent Substrate resuelve este problema suspendiendo los agentes inactivos y tomando una instantánea de la memoria activa (RAM) y los archivos locales del agente. Cuando el agente suspendido necesita volver a actuar, el sistema restablece su estado en una zona de pruebas disponible en menos de un segundo.

Agent Substrate se basa en las capacidades de la zona de pruebas del agente y la mejora evitando los cuellos de botella del plano de control estándar de Kubernetes. Como resultado, ejecuta muchos más agentes simultáneos por máquina y reduce drásticamente los tiempos de inicio de los agentes.

Las implementaciones estándar de Kubernetes (incluido Agent Sandbox) asocian cada carga de trabajo del agente con un Pod dedicado. Si bien Kubernetes es altamente escalable, está limitado por la capacidad de procesamiento de la programación y la latencia de inicio de los Pods. Además, Kubernetes no admite la hibernación de Pods, y mantener millones de agentes inactivos en un clúster agotaría los límites de Pods y la memoria del plano de control. Para evitar pagar por la capacidad de procesamiento inactiva, debes apagar los Pods y administrar el estado del agente en el almacenamiento externo. Agent Substrate resuelve estas limitaciones de escalamiento desacoplando el estado del agente de los Pods subyacentes: almacena millones de instantáneas de agentes suspendidos y los restablece a pedido en un grupo compartido de Workers activos.

Agent Substrate es un sistema de código abierto que implementas directamente en tus propios clústeres de GKE Standard. Si bien el proyecto principal se desarrolla en el repositorio de Agent Substrate de código abierto, Google proporciona herramientas y secuencias de comandos de implementación optimizadas para GKE en el repositorio de substrate-gke para los clientes Google Cloud que cumplen con los requisitos.

Beneficios de Agent Substrate

Puedes usar Agent Substrate para alcanzar los siguientes objetivos:

  • Ejecuta código no confiable de forma segura: Agent Substrate aplica el aislamiento del kernel y de la red para que puedas ejecutar código generado por IA sin poner en riesgo tu infraestructura más amplia.
  • Crea agentes con estado y de larga duración: La memoria de trabajo y los archivos de un agente se conservan en todas las sesiones. El agente se reanuda desde el punto exacto en el que se detuvo.
  • Responder a las solicitudes en tiempo real: Cuando una solicitud nueva activa un agente suspendido, el sistema restablece el estado del agente en una fracción de segundo.
  • Reduce los costos de procesamiento: Puedes ejecutar más agentes en menos máquinas compartiendo un grupo de zonas de pruebas de Worker en todos tus agentes. Como los agentes inactivos se suspenden y no usan CPU ni memoria, solo pagas por el procesamiento cuando los agentes procesan tareas de forma activa.

Casos de uso

Agent Substrate está diseñado para ejecutar agentes a cualquier escala, desde decenas hasta millones de agentes simultáneos. Estos son tres ejemplos de cargas de trabajo:

  • Agentes de productividad: Son asistentes en segundo plano a largo plazo que mantienen el contexto durante semanas. Dado que estos asistentes pasan la mayor parte del tiempo esperando activadores, suspender las cargas de trabajo cuando no se usan reduce los costos de procesamiento.
  • Zonas de pruebas efímeras: Son entornos aislados y a pedido para ejecutar código no confiable generado por LLM, ejecutar llamadas a herramientas o analizar datos. Debido a que las zonas de pruebas se restablecen en menos de un segundo, el sistema puede proporcionar entornos desechables para tareas de corta duración y liberar recursos cuando finaliza la ejecución.
  • Agentes de programación: Asistentes de IA que mantienen conversaciones en tiempo real con los desarrolladores para escribir, compilar y probar código. El agente ejecuta comandos de terminal y modifica archivos dentro de un entorno de pruebas. Cuando el agente está inactivo, el sistema lo suspende hasta que el desarrollador envía otra instrucción.

Cómo funciona Agent Substrate

Agent Substrate se basa en Kubernetes, pero no es necesario que comprendas Kubernetes para usarlo. Los conceptos básicos de Agent Substrate son los siguientes:

  • Actor: Es una sola instancia en ejecución de un agente.
  • ActorTemplate: Es un plano de configuración (que define imágenes de contenedores, variables de entorno y recursos de procesamiento) que se usa para crear instancias de Actors.
  • Worker: Es una zona de pruebas segura en la que se ejecuta un Actor activo.
  • WorkerPool: Es un grupo de trabajadores inactivos que se iniciaron previamente y que se mantienen listos para recibir un actor.

Como un actor no está vinculado a un trabajador específico, el sistema puede suspender los agentes inactivos y reutilizar el procesamiento liberado. Esta arquitectura permite que el sistema ejecute millones de agentes en una cantidad limitada de máquinas.

Un ciclo de vida típico del agente sigue estos pasos:

  1. Enrutamiento: Cada solicitud entrante a la API de tu aplicación especifica su Actor objetivo. Por ejemplo, cuando un usuario escribe una nueva instrucción en una interfaz de chat, tu aplicación envía una solicitud dirigida al Actor específico que administra la sesión del usuario.
  2. Reanudación: Si la solicitud es para un actor suspendido, el sistema reclama un trabajador activo del WorkerPool y restablece la instantánea del actor en ese trabajador.
  3. Ejecutando: El sistema enruta la solicitud a este Worker recién activado, y el Actor procesa la tarea.
  4. Suspensión: Cuando el actor termina su trabajo y queda inactivo, el sistema toma una instantánea nueva de la memoria y los archivos del actor, guarda la instantánea en el almacenamiento y libera el Worker vacío de nuevo en el grupo.

Aislamiento de cargas de trabajo y GKE Sandbox

Agent Substrate usa gVisor o Cloud Hypervisor para ejecutar cada carga de trabajo en un entorno de pruebas que aísla el código de la aplicación del kernel del host. La instalación de Agent Substrate incluye un tiempo de ejecución de gVisor para los Workers, por lo que no es necesario que configures GKE Sandbox en los nodos subyacentes de GKE.

Limitaciones y requisitos

Agent Substrate tiene las siguientes limitaciones y requisitos:

  • Versión del clúster y APIs beta: Agent Substrate es compatible con los clústeres estándar de GKE que ejecutan la versión 1.36 (con las marcas beta habilitadas) o la versión 1.37 o posterior. Las versiones anteriores a la 1.36 no son compatibles. Además, GKE requiere APIs beta (podcertificaterequests y clustertrustbundles). Si habilitas estas APIs en un clúster existente que ejecuta la versión 1.36, también debes reemplazar los nodos existentes para que la proyección de certificados de Pod esté habilitada en ellos. En la versión 1.37 o posterior, no es necesario reemplazar los nodos existentes.
  • Workload Identity Federation for GKE: Los clústeres de GKE deben tener habilitada la Workload Identity Federation for GKE. Agent Substrate usa Workload Identity Federation for GKE para autenticarse en las APIs de Google Cloud , como Cloud Storage para guardar instantáneas del agente.
  • Familias de VMs:
    • Arquitecturas de CPU mixtas: Agent Substrate no admite series de máquinas de uso general que se ejecutan en arquitecturas de CPU mixtas (como los tipos de máquinas E2) debido a un problema conocido con gVisor.
    • Tipos de VM uniformes por plantilla de Actor: No se admite la combinación de tipos de VM dentro de un solo ActorTemplate (el esquema de configuración que se usa para crear Actores). Por ejemplo, si tu clúster tiene dos grupos de nodos que usan VMs C4 y N2, un ActorTemplate debe incluir un selector de nodos que especifique un solo tipo de VM (como C4) para evitar que los actores de esa plantilla se dividan en diferentes tipos de máquinas.
  • Compatibilidad con GPU: No se admite la transferencia directa de dispositivos de GPU a contenedores de Actor. Si especificas nvidia.com/gpu, solo se colocarán los Pods en nodos habilitados para GPU, pero no se pasará el dispositivo de GPU al contenedor del actor. Además, gVisor no puede crear instantáneas de contextos CUDA activos.
  • Redes:
    • Políticas de salida: No se admiten las reglas de EgressPolicy (controles de red por nombre de host y dirección IP), incluidas las siguientes capacidades:
      • Reglas de denegación predeterminadas
      • Reglas basadas en nombres de host
      • Inserción de credenciales
    • Conexiones abiertas: Las conexiones de red abiertas (como las sesiones de bases de datos o las conexiones a servidores de MCP) no se conservan cuando se suspende un agente. El código del agente debe controlar la reconexión a servicios externos cuando se reanuda el agente.
  • Observabilidad y OpenTelemetry administrado: OpenTelemetry administrado para GKE tiene las siguientes limitaciones:
    • OpenTelemetry administrado para GKE está en versión preliminar.
    • No se admiten los conectores de recopilador, lo que requiere el uso de un medidor de proxy externo para la comparativa de telemetría.
    • Las implementaciones de recopiladores generan una sobrecarga de caché de la memoria que se escala de forma lineal con la cantidad de Pods en clústeres grandes.
    • TLS no es compatible con Managed OpenTelemetry para GKE.
  • Almacenamiento: El sistema requiere Cloud Storage para guardar las instantáneas de tus agentes.
  • Entorno de instalación: No puedes instalar Agent Substrate en Cloud Shell. Cloud Shell tiene un límite de almacenamiento en disco persistente de 5 GB, lo que no proporciona suficiente espacio en disco para la instalación. Debes instalar Agent Substrate desde una estación de trabajo local o una máquina virtual (VM) con suficiente espacio en el disco.

¿Qué sigue?