Acerca de Agent Sandbox en GKE

Agent Sandbox en Google Kubernetes Engine (GKE) te ayuda a ejecutar cargas de trabajo de agentes aisladas en Pods de Kubernetes dedicados. El aislamiento es importante cuando los agentes de IA ejecutan código no confiable generado por LLM. Para la mayoría de las cargas de trabajo de agentes, deberías usar Agent Substrate en GKE, ya que puede ejecutar más agentes en los mismos nodos. Usa Agent Sandbox en GKE cuando cada agente necesite un Pod dedicado, GPUs o TPUs, una PodSpec de Kubernetes completa o un clúster de GKE Autopilot. Para comparar Agent Sandbox en GKE con Agent Substrate en GKE y elegir una arquitectura para tus cargas de trabajo de agentes de IA, consulta Planifica una arquitectura para cargas de trabajo de agentes de IA en GKE.

Agent Sandbox es un proyecto de código abierto que se encuentra en Kubernetes SIG Apps. Para usar Agent Sandbox en GKE, instala el controlador de Agent Sandbox en tu clúster. Eres responsable de actualizar el controlador. Para obtener instrucciones, consulta Instala Agent Sandbox en GKE.

En este documento, se proporciona una descripción general conceptual de Agent Sandbox en GKE.

Por qué usar Agent Sandbox en GKE

Agent Sandbox en GKE le otorga a cada agente un Pod dedicado y aislado del kernel que administras con las APIs de Kubernetes estándar. Estos son algunos de los beneficios clave:

  • Aislamiento a nivel del kernel: Aísla el código no confiable generado por LLM del kernel del nodo con GKE Sandbox con gVisor o microVMs. Agent Sandbox en GKE también funciona con Kata Containers de código abierto autoadministrados que instalas en tus nodos en lugar de GKE Sandbox. Para obtener un instructivo sobre cómo usar Kata Containers de código abierto con Agent Sandbox en GKE, consulta Habilita Kata Containers en GKE.

  • Aprovisionamiento en menos de un segundo: Proporciona Pods precalentados para tus agentes, por lo general, en menos de un segundo, en lugar de esperar a que se programen y se inicien los Pods estándar de Kubernetes.

  • Extensibilidad nativa de la nube: Aprovecha la potencia del paradigma de Kubernetes y la infraestructura administrada de GKE.

Con una API declarativa y estandarizada, Agent Sandbox en GKE ofrece una experiencia de contenedor único que proporciona características de aislamiento y persistencia similares a las de una máquina virtual (VM), compilada por completo en primitivas de Kubernetes.

Casos de uso comunes de Agent Sandbox en GKE

Usa Agent Sandbox en GKE para las cargas de trabajo que requieren aislamiento, persistencia y una identidad estable. Entre los casos de uso de ejemplo, se incluyen los siguientes:

  • Entornos de ejecución de agentes de IA: Ejecuta código no confiable en un Pod que use gVisor o microVMs para aislar el código del kernel del nodo.
  • Entornos de desarrollo: Proporciona a los desarrolladores entornos de programación persistentes y aislados basados en la nube.
  • Notebooks y herramientas de investigación: Aloja sesiones de un solo contenedor para herramientas interactivas, como los notebooks de Jupyter.
  • Servicios de Pod único con estado: Ejecuta aplicaciones que necesitan una identidad y un almacenamiento estables sin la complejidad de un StatefulSet.
  • Administración programática de entornos: Usa los SDK de la biblioteca cliente proporcionados, como el SDK de Python de Agent Sandbox, para solicitar y administrar recursos de la zona de pruebas directamente desde la lógica de tu aplicación sin administrar YAML de Kubernetes.

Cómo funciona Agent Sandbox en GKE

Agent Sandbox en GKE usa un controlador personalizado y varias definiciones de recursos personalizados (CRD) de Kubernetes para administrar el ciclo de vida de los recursos de la zona de pruebas.

Arquitectura principal

  • Recurso personalizado de zona de pruebas: Es el recurso principal que representa un solo Pod con estado. El recurso administra nombres de host estables, identidades de red y almacenamiento persistente. Para suspender un agente inactivo, establece el campo spec.operatingMode de su recurso de zona de pruebas en Suspended. El controlador borra el Pod, pero conserva el recurso de zona de pruebas y sus volúmenes persistentes. Los datos en la memoria y los cambios en el sistema de archivos del contenedor se pierden, a menos que primero tomes una instantánea del Pod. Para reanudar el agente, vuelve a establecer el campo en Running. Agent Sandbox en GKE no detecta agentes inactivos; tu aplicación decide cuándo suspenderlos.
  • Router de zona de pruebas: Es un componente que proporciona un extremo estable y canaliza el tráfico a los Pods que ejecutan tus agentes, lo que abstrae la complejidad de las redes subyacentes.
  • Integración en las instantáneas de Pods: Agent Sandbox en GKE se integra en la función de instantáneas de Pods de GKE para suspender y reanudar las cargas de trabajo guardando y restableciendo el estado completo de un contenedor.

Modelo de reclamo

El modelo de reclamación es una función clave que separa la solicitud del usuario de un entorno de los detalles de implementación específicos, como dónde y cómo se aprovisiona la carga de trabajo. A diferencia de un StatefulSet estándar de Kubernetes, el modelo de reclamación te permite solicitar un recurso de zona de pruebas sin necesidad de administrar directamente las configuraciones de almacenamiento o Pod subyacentes.

El modelo de reclamación usa los recursos personalizados SandboxClaim, SandboxWarmPool y SandboxTemplate, y funciona de la siguiente manera:

  1. Los usuarios o las aplicaciones solicitan un recurso de zona de pruebas creando un recurso SandboxClaim que hace referencia a un recurso SandboxWarmPool. El grupo de preparación hace referencia al recurso SandboxTemplate que define la configuración del Pod.
  2. El controlador asigna un recurso de zona de pruebas listo (y su Pod en ejecución) del grupo de preparación a la reclamación. Si no hay ningún recurso de zona de pruebas en el grupo que esté listo, el controlador crea un recurso de zona de pruebas nuevo para la reclamación a partir de la plantilla.

Grupos preparados

La función de grupo de instancias en espera está diseñada para minimizar la latencia de inicio en situaciones de agentes de IA interactivos. Con un grupo de preparación, Agent Sandbox en GKE puede proporcionar entornos de ejecución en menos de un segundo. La función usa el recurso personalizado SandboxWarmPool y funciona de la siguiente manera:

  1. Un recurso SandboxWarmPool mantiene un grupo de recursos de zona de pruebas preparados previamente con Pods en estado listo.
  2. Cuando se crea un recurso SandboxClaim, el controlador asigna un recurso Sandbox listo y su Pod en ejecución desde el grupo en lugar de esperar a que un Pod nuevo extraiga imágenes y se inicie.
  3. Cuando se combinan con instantáneas de Pods, los grupos de preparación pueden restablecer los Pods desde un estado preconfigurado en lugar de iniciarlos desde cero.

Aislamiento de red

Agent Sandbox en GKE implementa una política de red de denegación predeterminada para los Pods que el controlador crea a partir de un recurso SandboxTemplate. Para cada recurso SandboxTemplate, el controlador crea un recurso NetworkPolicy que ayuda a evitar que el código no confiable dentro del Pod acceda a redes internas no autorizadas o al plano de control de GKE. Puedes definir restricciones de red específicas y reglas de entrada o salida permitidas dentro de tu recurso SandboxTemplate para controlar el acceso a la red de las cargas de trabajo de los agentes.

El controlador no crea un recurso NetworkPolicy para un recurso de zona de pruebas que creas directamente. Para restringir el acceso a la red de los Pods de estos recursos de Sandbox, crea tu propio recurso NetworkPolicy.

Acceso programático con SDKs

Los ingenieros de IA pueden consumir recursos de Agent Sandbox en GKE de forma programática con las bibliotecas cliente proporcionadas. Por ejemplo, el SDK de Python proporciona una interfaz de alto nivel que crea el recurso SandboxClaim subyacente por ti. La reclamación hace referencia a un recurso SandboxWarmPool que creas. Esta interfaz te permite crear entornos aislados e interactuar con ellos directamente desde tus frameworks de agentes de IA basados en Python, como LangChain o el SDK de Vertex AI Agentic.

Limitaciones y requisitos

Agent Sandbox en GKE tiene las siguientes limitaciones y requisitos:

  • Versión del clúster: Agent Sandbox en GKE se ejecuta en cualquier versión compatible de GKE. Para usar las instantáneas de Pods, tu clúster debe ejecutar la versión 1.35.3-gke.1234000 o posterior de GKE.
  • Requisitos de infraestructura: Requiere que el controlador de Agent Sandbox esté instalado y configurado en el clúster. Agent Sandbox en GKE no requiere un tipo de máquina específico. Por ejemplo, en la guía de instalación, se usan nodos e2-standard-2. Sin embargo, las instantáneas de Pods no admiten tipos de máquinas E2, por lo que, si planeas usarlas, utiliza otra serie de máquinas, como N2.
  • Entornos de ejecución de aislamiento: Agent Sandbox en GKE admite gVisor y microVMs como entornos de ejecución de aislamiento. Las instantáneas de Pods requieren gVisor y no funcionan con microVMs. Si no especificas un entorno de ejecución de GKE Sandbox (gVisor o microVMs), tus Pods se ejecutarán sin aislamiento del kernel, por lo que no debes usarlos para ejecutar código no confiable.
  • Aceleradores de hardware: Las GPU y las TPU solo funcionan con el entorno de ejecución de gVisor en los modelos de GPU y las versiones de TPU compatibles, y no se admiten con microVMs. Además, las instantáneas de Pods no admiten TPUs.
  • Disponibilidad de las funciones subyacentes: Algunas funciones subyacentes, como las instantáneas de Pods de GKE, pueden estar en versión preliminar o tener disponibilidad regional específica.

¿Qué sigue?