À propos d'Agent Sandbox sur GKE

Agent Sandbox sur Google Kubernetes Engine (GKE) vous aide à exécuter des charges de travail d'agent isolées dans des pods Kubernetes dédiés. L'isolation est importante lorsque les agents IA exécutent du code non fiable généré par un LLM. Pour la plupart des charges de travail d'agent, vous devez plutôt utiliser Agent Substrate sur GKE, car il peut exécuter davantage d'agents sur les mêmes nœuds. Utilisez Agent Sandbox sur GKE lorsque chaque agent a besoin d'un pod dédié, de GPU ou de TPU, d'un PodSpec Kubernetes complet ou d'un cluster GKE Autopilot. Pour comparer Agent Sandbox sur GKE avec Agent Substrate sur GKE et choisir une architecture pour vos charges de travail d'agent IA, consultez Planifier une architecture pour les charges de travail d'agent IA sur GKE.

Agent Sandbox est un projet Open Source sous Kubernetes SIG Apps. Pour utiliser Agent Sandbox sur GKE, vous devez installer le contrôleur Agent Sandbox sur votre cluster. Vous êtes responsable de la mise à niveau du contrôleur. Pour obtenir des instructions, consultez Installer Agent Sandbox sur GKE.

Ce document présente le concept d'Agent Sandbox sur GKE.

Pourquoi utiliser Agent Sandbox sur GKE ?

Agent Sandbox sur GKE fournit à chaque agent un pod dédié isolé du noyau que vous gérez avec les API Kubernetes standards. Les principaux avantages sont les suivants :

  • Isolation au niveau du noyau : isole le code non approuvé généré par LLM du noyau du nœud à l'aide de GKE Sandbox avec gVisor ou des microVM. Agent Sandbox sur GKE fonctionne également avec les Kata Containers Open Source autogérés que vous installez sur vos nœuds au lieu de GKE Sandbox. Pour découvrir comment utiliser les Kata Containers Open Source avec Agent Sandbox sur GKE, consultez Activer les Kata Containers sur GKE.

  • Provisionnement en moins d'une seconde : fournit des pods préchauffés pour vos agents, généralement en moins d'une seconde, au lieu d'attendre la planification et le démarrage standards des pods Kubernetes.

  • Extensibilité cloud native : exploite la puissance du paradigme Kubernetes et de l'infrastructure gérée de GKE.

En fournissant une API déclarative et standardisée, Agent Sandbox sur GKE offre une expérience de conteneur unique qui fournit des caractéristiques d'isolation et de persistance similaires à celles d'une machine virtuelle (VM), entièrement basée sur des primitives Kubernetes.

Cas d'utilisation courants d'Agent Sandbox sur GKE

Utilisez Agent Sandbox sur GKE pour les charges de travail qui nécessitent une isolation, une persistance et une identité stable. Voici quelques exemples de cas d'utilisation :

  • Environnements d'exécution d'agents IA : exécutez du code non approuvé dans un pod qui utilise gVisor ou des microVMs pour isoler le code du noyau du nœud.
  • Environnements de développement : fournissez aux développeurs des environnements de codage persistants et isolés dans le cloud.
  • Notebooks et outils de recherche : hébergez des sessions à conteneur unique pour des outils interactifs tels que les notebooks Jupyter.
  • Services à pod unique avec état : exécutez des applications qui nécessitent une identité et un stockage stables sans la complexité d'un StatefulSet.
  • Gestion programmatique de l'environnement : utilisez les SDK de bibliothèque cliente fournis, tels que le SDK Python Agent Sandbox, pour demander et gérer des ressources de bac à sable directement à partir de la logique de votre application sans gérer le YAML Kubernetes.

Fonctionnement d'Agent Sandbox sur GKE

Agent Sandbox sur GKE utilise un contrôleur personnalisé et plusieurs définitions de ressources personnalisées (CRD) Kubernetes pour gérer le cycle de vie des ressources Sandbox.

Architecture de base

  • Ressource personnalisée Sandbox : ressource principale qui représente un seul pod avec état. La ressource gère les noms d'hôte stables, l'identité réseau et le stockage persistant. Pour suspendre un agent inactif, définissez le champ spec.operatingMode de sa ressource Sandbox sur Suspended. Le contrôleur supprime le pod, mais conserve la ressource Sandbox et ses volumes persistants. Les données en mémoire et les modifications du système de fichiers du conteneur sont perdues, sauf si vous prenez d'abord un instantané du pod. Pour réactiver l'agent, redéfinissez le champ sur Running. Agent Sandbox sur GKE ne détecte pas les agents inactifs. C'est votre application qui décide quand les suspendre.
  • Routeur de bac à sable : composant qui fournit un point de terminaison stable et achemine le trafic vers les pods qui exécutent vos agents, en faisant abstraction de la complexité de la mise en réseau sous-jacente.
  • Intégration aux instantanés de pods : Agent Sandbox sur GKE s'intègre à la fonctionnalité d'instantanés de pods GKE pour suspendre et reprendre les charges de travail en enregistrant et en restaurant l'état complet d'un conteneur.

Modèle de revendication

Le modèle de revendication est une fonctionnalité clé qui sépare la demande d'environnement de l'utilisateur des détails d'implémentation spécifiques, tels que l'emplacement et la manière dont la charge de travail est provisionnée. Contrairement à un StatefulSet Kubernetes standard, le modèle de revendication vous permet de demander une ressource de bac à sable sans avoir à gérer directement les configurations de pod ou de stockage sous-jacentes.

Le modèle de revendication utilise les ressources personnalisées SandboxClaim, SandboxWarmPool et SandboxTemplate, et fonctionne comme suit :

  1. Les utilisateurs ou les applications demandent une ressource Sandbox en créant une ressource SandboxClaim qui référence une ressource SandboxWarmPool. Le pool de préchauffage fait référence à la ressource SandboxTemplate qui définit la configuration du pod.
  2. Le contrôleur attribue une ressource Sandbox prête (et son pod en cours d'exécution) du pool chaud à la revendication. Si aucune ressource Sandbox du pool n'est prête, le contrôleur crée une ressource Sandbox pour la revendication à partir du modèle.

Pools préprovisionnés

La fonctionnalité de pool de préchauffage est conçue pour minimiser la latence de démarrage dans les scénarios d'agents IA interactifs. En utilisant un pool chaud, Agent Sandbox sur GKE peut fournir des environnements d'exécution en moins d'une seconde. La fonctionnalité utilise la ressource personnalisée SandboxWarmPool et fonctionne comme suit :

  1. Une ressource SandboxWarmPool gère un pool de ressources Sandbox préprovisionnées avec des pods à l'état prêt.
  2. Lorsqu'une ressource SandboxClaim est créée, le contrôleur attribue une ressource Sandbox prête et son pod en cours d'exécution à partir du pool, au lieu d'attendre qu'un nouveau pod extrait des images et démarre.
  3. Lorsqu'ils sont combinés à des instantanés de pods, les pools de préchauffage peuvent restaurer les pods à partir d'un état préconfiguré au lieu de les démarrer à partir de zéro.

Isolation du réseau

Agent Sandbox sur GKE implémente une règle de réseau de refus par défaut pour les pods que le contrôleur crée à partir d'une ressource SandboxTemplate. Pour chaque ressource SandboxTemplate, le contrôleur crée une ressource NetworkPolicy qui empêche le code non fiable à l'intérieur du pod d'accéder à des réseaux internes non autorisés ou au plan de contrôle GKE. Vous pouvez définir des restrictions réseau spécifiques et des règles d'entrée ou de sortie autorisées dans votre ressource SandboxTemplate pour contrôler l'accès réseau des charges de travail de l'agent.

Le contrôleur ne crée pas de ressource NetworkPolicy pour une ressource Sandbox que vous créez directement. Pour limiter l'accès réseau aux pods de ces ressources Sandbox, créez votre propre ressource NetworkPolicy.

Accès programmatique avec des SDK

Les ingénieurs en IA peuvent utiliser Agent Sandbox sur les ressources GKE de manière programmatique à l'aide des bibliothèques clientes fournies. Par exemple, le SDK Python fournit une interface de haut niveau qui crée la ressource SandboxClaim sous-jacente pour vous. La revendication fait référence à une ressource SandboxWarmPool que vous créez. Cette interface vous permet de créer des environnements isolés et d'interagir avec eux directement depuis vos frameworks d'agents basés sur Python, comme LangChain ou le SDK Vertex AI Agentic.

Limites et exigences

Agent Sandbox sur GKE présente les limites et exigences suivantes :

  • Version du cluster : Agent Sandbox sur GKE s'exécute sur n'importe quelle version de GKE compatible. Pour utiliser les instantanés de pods, votre cluster doit exécuter GKE version 1.35.3-gke.1234000 ou ultérieure.
  • Exigences d'infrastructure : nécessite que le contrôleur Agent Sandbox soit installé et configuré sur le cluster. Agent Sandbox sur GKE ne nécessite pas de type de machine spécifique. Par exemple, le guide d'installation utilise des nœuds e2-standard-2. Toutefois, les instantanés de pods ne sont pas compatibles avec les types de machines E2. Par conséquent, si vous prévoyez d'utiliser des instantanés de pods, utilisez une autre série de machines, telle que N2.
  • Environnements d'exécution d'isolation : Agent Sandbox sur GKE est compatible avec gVisor et les microVMs en tant qu'environnements d'exécution d'isolation. Les instantanés de pods nécessitent gVisor et ne fonctionnent pas avec les microVM. Si vous ne spécifiez pas d'environnement d'exécution GKE Sandbox (gVisor ou microVM), vos pods s'exécutent sans isolation du noyau. Ne les utilisez donc pas pour exécuter du code non approuvé.
  • Accélérateurs matériels : les GPU et les TPU ne fonctionnent qu'avec l'environnement d'exécution gVisor sur les modèles de GPU et les versions de TPU compatibles. Ils ne sont pas compatibles avec les microVM. De plus, les instantanés de pods ne sont pas compatibles avec les TPU.
  • Disponibilité des fonctionnalités sous-jacentes : certaines fonctionnalités sous-jacentes, telles que les instantanés de pods GKE, peuvent être en version preview ou avoir une disponibilité régionale spécifique.

Étapes suivantes