Planifica una arquitectura para cargas de trabajo de agentes de IA en GKE

Google Kubernetes Engine (GKE) proporciona dos modelos de organización para ejecutar agentes de IA dentro de entornos de pruebas aislados del kernel (con microVMs de Cloud Hypervisor o gVisor):

  • Agent Substrate en GKE (basado en actores, recomendado): Usa este modelo para la mayoría de las cargas de trabajo de agentes de IA, en especial, los agentes con estado basados en CPU que se suspenden y reanudan con frecuencia. Las sesiones de agentes activas (actores) comparten un grupo de Pods de trabajadores activos y se pueden restablecer desde Cloud Storage en menos de un segundo.
  • Agent Sandbox en GKE (basado en Pods): Usa este modelo cuando cada agente requiera un Pod de Kubernetes dedicado. Elige esta opción para agentes o cargas de trabajo activos de forma continua que necesiten una PodSpec de Kubernetes completa (como sidecars), GPU o TPU, nodos de Arm o clústeres de GKE Autopilot.

Para obtener un resumen comparativo de los dos modelos de organización, consulta Compara Agent Substrate y Agent Sandbox.

Lee este documento para elegir un modelo de organización, un entorno de ejecución de zona de pruebas, controles de aislamiento y opciones de almacenamiento antes de aprovisionar tu clúster de GKE. Este documento está dirigido a arquitectos de soluciones, desarrolladores de IA, y administradores y operadores de plataformas que diseñan entornos de ejecución para agentes de IA en GKE.

Requisitos de arquitectura para las cargas de trabajo de agentes de IA en GKE

Ejecutar cargas de trabajo de agentes de IA en GKE te permite colocar entornos de ejecución de agentes aislados en el mismo clúster y perímetro de red que tus servicios de Kubernetes de respaldo, y usar GKE para el aprovisionamiento automático de nodos, el escalamiento de ráfagas y la administración del ciclo de vida.

A diferencia de los microservicios activos de forma continua, las cargas de trabajo de los agentes de IA tienen los siguientes requisitos de arquitectura:

Modelo basado en actores: Agent Substrate en GKE (recomendado)

Agent Substrate en GKE es un entorno de ejecución que separa las sesiones de los agentes (actores) de los Pods de Kubernetes subyacentes. Los actores activos comparten un grupo de Pods de trabajadores preparados previamente (recursos WorkerPool) en las plantillas de actores (recursos ActorTemplate). Cuando tu aplicación suspende un actor inactivo, Agent Substrate crea un punto de control del estado del actor en Cloud Storage y libera su capacidad de trabajador para que otros actores puedan usar el nodo. Cuando llega una solicitud nueva, Agent Substrate restablece el actor en un trabajador disponible en menos de un segundo.

Usa Agent Substrate como tu arquitectura predeterminada para las cargas de trabajo de agentes basadas en CPU, incluidos los siguientes casos de uso:

  • Agentes de programación interactivos: Son asistentes de IA que ejecutan comandos de terminal, compilan código y editan archivos durante las conversaciones con los desarrolladores, y se suspenden entre las instrucciones.
  • Agentes de productividad de larga duración: Son asistentes en segundo plano que mantienen el contexto durante días o semanas, y pasan la mayor parte del tiempo esperando la entrada del usuario o activadores externos.
  • Zonas de pruebas de código y navegador efímeras: Son entornos a pedido para ejecutar código generado por LLM, navegadores sin interfaz gráfica o llamadas a la herramienta que se restablecen en menos de un segundo y liberan cómputo después de la ejecución.

Agent Substrate requiere clústeres de GKE Standard (versión 1.37 o posterior tanto en el plano de control como en los grupos de nodos) con nodos trabajadores de CPU x86. No se admite GKE Autopilot porque el agente de nodo de Agent Substrate (atelet) se ejecuta como un DaemonSet con privilegios, y los grupos de trabajadores de microVM requieren virtualización anidada o nodos de equipos físicos. No se admiten GPU ni TPU.

Identidad, credenciales y salida de red

Agent Substrate aprovisiona un certificado SPIFFE X.509 único y un token web JSON (JWT) para que cada actor autentique y audite las solicitudes de sesiones individuales. Debido a que varios actores comparten Pods de trabajador con el tiempo, usa la federación de identidades para cargas de trabajo para GKE a nivel del Pod solo para las tareas de infraestructura de trabajador.

Para mantener las claves de API y los tokens fuera de la zona de pruebas, la puerta de enlace de salida integrada inserta credenciales en las solicitudes salientes en tránsito. Los Secrets se almacenan en objetos Secret de Kubernetes o en Secret Manager. Cuando una solicitud HTTP o HTTPS saliente coincide con una regla de salida, la puerta de enlace autentica el túnel mTLS del actor y reemplaza los encabezados de marcador de posición por un secreto recuperado o un JWT de actor. Para obtener más información, consulta la documentación de código abierto de Agent Substrate sobre la inserción de credenciales de salida.

De forma predeterminada, Agent Substrate bloquea todo el tráfico saliente hacia otros actores, el plano de control de Kubernetes, el servidor de metadatos de Compute Engine y la Internet. Se bloquean las conexiones UDP que no son de DNS, las conexiones TCP sin procesar arbitrarias y las actualizaciones de WebSocket HTTP, y la resolución de DNS solo resuelve los nombres de host permitidos por el recurso EgressPolicy del actor. Para permitir conexiones salientes, define reglas de transferencia de HTTP, HTTPS o TLS en el recurso EgressPolicy con nombres de dominio completamente calificados (FQDN) o nombres de host comodín. No se admiten direcciones IP ni rangos CIDR. Para obtener más información, consulta la documentación de código abierto de Agent Substrate sobre el tráfico de salida y la seguridad.

Puntos de control de la sesión y almacenamiento del lugar de trabajo

Cuando tu aplicación suspende un agente (en gVisor o microVMs), Agent Substrate guarda una instantánea en Cloud Storage en tres capas: memoria activa, cambios en el sistema de archivos raíz y directorios duraderos (la capa de volúmenes). Los volúmenes de CSI externos conectados persisten en su almacenamiento de respaldo fuera de la instantánea y se vuelven a conectar cuando se reanuda la VM.

Cuando se reanuda un actor suspendido, Agent Substrate restablece la capa de instantánea más alta que coincida con el entorno de destino:

  • Memoria, sistema de archivos raíz y volúmenes: Se restablecen en menos de un segundo cuando el actor se reanuda con el mismo hardware, entorno de ejecución de zona de pruebas y imagen de contenedor.
  • Sistema de archivos raíz y volúmenes: Se restablecen cuando cambia el hardware del nodo o el entorno de ejecución de la zona de pruebas. El actor reinicia sus procesos mientras conserva los cambios en el sistema de archivos raíz y los directorios duraderos.
  • Solo volúmenes: Se restablecen cuando actualizas la imagen de contenedor en el recurso ActorTemplate mientras el actor está suspendido. La próxima reanudación inicia los contenedores desde la imagen actualizada y restablece los directorios duraderos y los volúmenes externos. Escribe datos que deban sobrevivir a las actualizaciones de imágenes en directorios duraderos o en un almacenamiento externo.

La latencia de suspensión y reanudación aumenta con el tamaño de la instantánea. Para los espacios de trabajo grandes que necesitan volver a conectarse con rapidez entre nodos cuando un actor se reanuda en un nodo diferente, usa volúmenes de agentes de Filestore externos en lugar de almacenar los datos dentro de la instantánea. Cada volumen de CSI externo (versión preliminar) en un recurso ActorTemplate se aprovisiona exclusivamente para un solo actor (no se comparte entre actores) y se borra con ese actor. La asistencia de producción para los volúmenes de agentes de Filestore se ofrece a través de un programa de DG limitado que requiere una solicitud de acceso.

El almacenamiento en bloque (como Hyperdisk) se usa para los discos de arranque de los nodos y el almacenamiento en caché de instantáneas locales, en lugar de los volúmenes de CSI por actor, ya que la latencia de desconexión y conexión de bloques entre nodos ralentiza la reanudación de los actores. Para obtener más información, consulta la documentación de código abierto de los volúmenes de CSI de Agent Substrate.

Modelo basado en Pods: Agent Sandbox en GKE

Agent Sandbox en GKE ejecuta cada agente en un Pod de Kubernetes dedicado con estado que se administra a través de recursos personalizados de Kubernetes (Sandbox, SandboxClaim, SandboxTemplate y SandboxWarmPool). Un recurso SandboxWarmPool mantiene recursos de zona de pruebas preparados con Pods en ejecución para un recurso SandboxTemplate específico, de modo que el controlador pueda asignar un recurso de zona de pruebas listo y su Pod en ejecución a una reclamación en menos de un segundo.

Elige Agent Sandbox cuando cada agente necesite un Pod dedicado o cuando tus cargas de trabajo tengan alguno de los siguientes requisitos:

  • Agentes activos de forma continua y servicios de un solo Pod: Son cargas de trabajo sin períodos de inactividad frecuentes o sesiones persistentes (como entornos de desarrollo en la nube o notebooks de Jupyter) que necesitan un nombre de host y un almacenamiento estables sin la complejidad de StatefulSet.
  • Aceleradores de hardware (GPU o TPU): Agentes que necesitan acceso directo a las GPU o TPU dentro de la zona de pruebas. Los aceleradores solo funcionan con el entorno de ejecución de gVisor en los modelos de GPU y las versiones de TPU compatibles. Las microVMs no admiten GPUs ni TPUs.
  • PodSpec de Kubernetes completo, nodos de Arm o GKE Autopilot: cargas de trabajo que requieren contenedores de inicio o de sidecar personalizados, APIs y herramientas estándar de Kubernetes (por ejemplo, comandos de kubectl, control de acceso basado en roles y controladores existentes), CPUs de Arm o clústeres de GKE Autopilot.

Identidad, credenciales y políticas de red

Debido a que cada agente se ejecuta en un Pod dedicado, puedes otorgar permisos de Identity and Access Management (IAM) de Google Cloud al Pod con la federación de identidades para cargas de trabajo para GKE o la identidad del agente (versión preliminar). Ambas opciones vinculan la identidad a la ServiceAccount de Kubernetes del Pod en el momento de su creación, por lo que todos los Pods precalentados en un recurso SandboxWarmPool comparten la misma identidad. Para aislar las identidades por agente o usuario, mantén un recurso SandboxWarmPool independiente por identidad o crea recursos Sandbox on demand sin un grupo de preparación.

Los Secrets se activan en los Pods con objetos Secret de Kubernetes estándar o volúmenes de CSI. Agent Sandbox no incluye una puerta de enlace para la inserción de credenciales fuera de la zona de pruebas. Para insertar credenciales en tránsito, implementa tu propio proxy externo.

El controlador crea un objeto NetworkPolicy de denegación predeterminada para cada recurso SandboxTemplate. Para los recursos de Sandbox que creas directamente sin una plantilla, crea tu propio objeto NetworkPolicy. Restringes el tráfico con los controles de red estándar de GKE:

Suspensión por inactividad, instantáneas de Pods y almacenamiento

Un Pod de agente inactivo conserva su CPU y memoria reservadas hasta que tu aplicación suspende el recurso de Sandbox configurando su campo spec.operatingMode como Suspended. Si suspendes el recurso de zona de pruebas, se borrará el Pod, pero se conservarán sus volúmenes persistentes. Borrar el Pod borra los datos en la memoria y los cambios en el sistema de archivos del contenedor. Para guardar y restablecer ese estado desde Cloud Storage, toma una instantánea del Pod de GKE antes de suspender el agente. Las instantáneas de Pods requieren el entorno de ejecución de gVisor y no admiten microVMs ni TPUs. Restablecer un Pod a partir de una instantánea tarda aproximadamente entre tres y cinco segundos.

Para el almacenamiento persistente más allá de las instantáneas de Pods, elige entre las siguientes opciones:

Compara Agent Substrate y Agent Sandbox

En la siguiente tabla, se resumen las diferencias arquitectónicas entre Agent Substrate en GKE y Agent Sandbox en GKE:

Dimensión Agent Substrate en GKE (basado en actores) Agent Sandbox en GKE (basado en Pods)
Cargas de trabajo recomendadas para agentes de IA La mayoría de los agentes con estado basados en CPU que se suspenden y reanudan con frecuencia Agentes activos de forma continua, cargas de trabajo de GPU o TPU, PodSpecs personalizados, nodos de Arm o GKE Autopilot
Unidad de programación Varios actores comparten un grupo de Pods preparados (WorkerPool) Un Pod dedicado por agente (zona de pruebas)
Entornos de ejecución de zona de pruebas MicroVMs de gVisor y Cloud Hypervisor (administradas dentro de los Pods de WorkerPool) gVisor y microVMs en GKE Standard (con GKE Sandbox habilitado en el grupo de nodos o ComputeClass), o gVisor en GKE Autopilot (habilitado de forma predeterminada)
Agrupación de instancias preparadas Recursos de WorkerPool compartidos entre plantillas de actores e imágenes de contenedor Un recurso SandboxWarmPool por plantilla y por imagen de contenedor
Ruta de acceso del plano de control Plano de control y base de datos dedicados fuera del componente kube-apiserver Controladores estándares de Kubernetes, kube-apiserver y etcd
Manejo de recursos inactivos Cuando se suspende un actor inactivo, se liberan la CPU y la memoria de su trabajador Cuando se suspende un recurso de Sandbox inactivo, se borra su Pod y se conservan los volúmenes persistentes
Puntos de control de estado Instantáneas de Cloud Storage integradas en gVisor y microVMs, que se restablecen en menos de un segundo Instantáneas de Pods de GKE (solo compatibles con gVisor), que se restablecen en un plazo de 3 a 5 segundos
Modos de clúster compatibles GKE Standard (versión 1.37 o posterior, nodos x86) GKE Standard y GKE Autopilot
Aceleradores de hardware No se admite (nodos trabajadores solo de CPU) Las GPU y TPU solo se admiten con el entorno de ejecución de gVisor
Compatibilidad con PodSpec de Kubernetes Subconjunto dividido entre los recursos ActorTemplate y WorkerPool PodSpec completo, incluidos los sidecars y los contenedores de inicialización
Redes Puertas de enlace de entrada y salida de Envoy integradas con túneles mTLS por actor Services, NetworkPolicy y FQDNNetworkPolicy de Kubernetes
Modelo de identidad Certificado X.509 y JWT de SPIFFE por actor ServiceAccount del Pod que usa Workload Identity Federation for GKE o Agent Identity (Preview), compartida en un grupo de preparación
Administración de Secrets Se inserta en las solicitudes salientes en la puerta de enlace de salida. Se activan en el Pod con objetos Secret de Kubernetes o volúmenes de CSI.

Selecciona un entorno de ejecución de zona de pruebas

Tanto Agent Substrate como Agent Sandbox aíslan el código no confiable del nodo host con microVMs de Cloud Hypervisor o gVisor, pero el entorno de ejecución se configura de manera diferente en cada modelo:

  • Agent Substrate: Selecciona el entorno de ejecución en el recurso WorkerPool. Agent Substrate administra sus propios entornos de ejecución de microVM y gVisor dentro de sus Pods de WorkerPool, en lugar de usar la función de GKE Sandbox a nivel del nodo. No habilites GKE Sandbox en los grupos de nodo trabajador de Agent Substrate, ya que el taint de nodo sandbox.gke.io/runtime impide que se programen los Pods de WorkerPool.
  • Agent Sandbox: Establece el campo runtimeClassName en gvisor o microvm en la plantilla de Pod de tu recurso SandboxTemplate. En GKE Standard, también habilita GKE Sandbox en el grupo de nodos o en una ComputeClass personalizada. En GKE Autopilot, gVisor está disponible de forma predeterminada y las microVMs no son compatibles.

Ambos entornos de ejecución ejecutan código no confiable y navegadores sin interfaz gráfica:

  • MicroVMs: Cada zona de pruebas se ejecuta en una máquina virtual ligera con un kernel de Linux invitado dedicado. Elige microVMs cuando necesites aislamiento a nivel de VM, compatibilidad total con llamadas al sistema de Linux o límites de CPU y memoria por contenedor dentro de un actor de varios contenedores.
  • gVisor: Cada zona de pruebas se ejecuta en un kernel de espacio de usuario que intercepta y filtra las llamadas del sistema de Linux. Elige gVisor para obtener inicios en frío más rápidos, una menor sobrecarga de memoria o una compatibilidad más amplia con las máquinas de Compute Engine (incluidas las GPU, las TPU, los nodos de Arm y GKE Autopilot en Agent Sandbox).

En la siguiente tabla, se comparan las microVMs y gVisor en GKE:

Función MicroVMs gVisor
Acceso al kernel Kernel de Linux completo Subconjunto de llamadas al sistema del kernel de Linux
Nivel de aislamiento Virtualización de hardware con un kernel invitado dedicado Intercepción de llamadas al sistema en un kernel de espacio de usuario
Sobrecarga de CPU y memoria Memoria de VMM por actor en Agent Substrate. Se corrigieron 250 mCPU y 130 MiB por Pod en GKE Sandbox. Sobrecarga dinámica con memoria base baja
Hora de inicio De 1 a 2 segundos Menos de 100 ms
Configuración de nodos de GKE Nodos de GKE Standard con virtualización anidada (ambos modelos) o nodos de equipos físicos x86 (solo Agent Substrate) Grupos de nodos de GKE Standard (ambos modelos) o nodos de GKE Autopilot (solo Agent Sandbox)
Compatibilidad con imágenes de nodo Container-Optimized OS (cos_containerd) en Agent Substrate. Container-Optimized OS (cos_containerd) o Ubuntu en GKE Sandbox. Solo Container-Optimized OS (cos_containerd)
Compatibilidad de tipos de máquinas Series de máquinas x86 que admiten la virtualización anidada y equipos físicos x86 (no se admiten en E2 ni Arm) Series x86 de CPU no mixtas en Agent Substrate La mayoría de las series de x86, Arm y aceleradores en Agent Sandbox.
Compatibilidad con aceleradores No compatible Modelos de GPU y versiones de TPU compatibles (solo Agent Sandbox)
Ejemplos de casos de uso
  • Agentes de programación y de navegador autónomos
  • Cargas de trabajo que requieren compatibilidad total con el kernel de Linux
  • Cargas de trabajo con alta E/S y llamadas al sistema frecuentes
  • Aplicaciones no confiables en Python, Node.js, Go, Java o Rust
  • Inferencia de CPU, GPU o TPU, y entornos de pruebas de ejecución de código
  • Frontends, cachés y proxies web

Para obtener más información sobre estas tecnologías de aislamiento, consulta GKE Sandbox.

¿Qué sigue?