À propos du bac à sable de l'agent GKE

GKE Agent Sandbox vous aide à gérer les charges de travail isolées, avec état et à réplica unique sur GKE. Il est optimisé pour les cas d'utilisation tels que les environnements d'exécution d'agents d'IA, où le code non approuvé généré par un LLM doit être exécuté dans un environnement sécurisé et performant.

L'add-on GKE Agent Sandbox est basé sur le projet de contrôleur Open Source Agent Sandbox et suit ses cycles de publication. En tant qu'add-on GKE géré, Google gère l'ensemble du cycle de vie du contrôleur, y compris les mises à niveau automatiques et les correctifs de sécurité.

Ce document présente les concepts liés à GKE Agent Sandbox.

Pourquoi utiliser GKE Agent Sandbox ?

GKE Agent Sandbox est conçu pour les charges de travail d'agent qui nécessitent une évolutivité, une extensibilité et une sécurité de haut niveau. Principaux avantages :

  • Isolation au niveau du noyau : fournit une isolation forte au niveau du noyau pour le code non approuvé généré par un LLM à l'aide de technologies telles que gVisor.
  • Provisionnement en moins d'une seconde : offre un mécanisme prêt à l'emploi pour fournir des bacs à sable beaucoup plus rapidement que ne le permet la planification standard des pods Kubernetes (généralement moins d'une seconde).
  • Extensibilité native du cloud : exploite la puissance du paradigme Kubernetes et de l'infrastructure gérée de GKE.

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

Cas d'utilisation courants d'Agent Sandbox

Utilisez GKE Agent Sandbox 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 d'IA : exécutez en toute sécurité du code non approuvé dans un environnement isolé par des environnements d'exécution axés sur la sécurité, tels que gVisor.
  • Environnements de développement : fournissez aux développeurs des environnements de codage persistants, isolés et basés sur 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 bacs à sable directement à partir de la logique de votre application sans gérer le YAML Kubernetes.

Fonctionnement de GKE Agent Sandbox

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

Architecture de base

  • CRD Sandbox : ressource principale qui représente un pod unique avec état. Elle gère les noms d'hôte stables, l'identité réseau et le stockage persistant.
  • Routeur Sandbox : composant qui fournit un point de terminaison stable et achemine le trafic vers les pods Sandbox appropriés, en faisant abstraction de la complexité du réseau sous-jacent.
  • Intégration aux instantanés de pod : GKE Agent Sandbox s'intègre à la fonctionnalité d'instantanés de pod GKE pour permettre la mise en pause et la reprise des 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 le mode de provisionnement de la charge de travail. Contrairement à un StatefulSet Kubernetes standard, le modèle de revendication vous permet de demander un bac à sable sans avoir à gérer directement les configurations de pod ou de stockage sous-jacentes.

Le modèle de revendication est géré à l'aide des SandboxClaim et SandboxTemplate CRD, et fonctionne comme suit :

  1. Les utilisateurs ou les applications demandent un bac à sable en créant un SandboxClaim qui fait référence à un SandboxTemplate.
  2. Le contrôleur gère le mappage de la revendication à une instance Sandbox réelle, offrant ainsi une gestion flexible du backend. Cela permet au système de réutiliser les bacs à sable existants ou d'allouer des ressources à partir d'un pool.

Pools d'eau chaude

La fonctionnalité Pool d'eau chaude est conçue pour minimiser la latence de démarrage, ce qui est essentiel pour les scénarios d'agents d'IA interactifs. Cette fonctionnalité permet à Agent Sandbox de fournir des environnements d'exécution en moins d'une seconde, ce qui est beaucoup plus rapide que la planification typique des pods. La fonctionnalité est gérée à l'aide de la SandboxWarmPool CRD et fonctionne de la manière suivante :

  1. Un SandboxWarmPool gère un ensemble d'instances de pod préchauffées dans un état prêt.
  2. Lorsqu'une SandboxClaim est effectuée, le contrôleur attribue instantanément un pod du pool au lieu d'attendre qu'un nouveau pod extrait des images et démarre à partir de zéro.
  3. Combinés aux instantanés de pod, les pools d'eau chaude offrent des fonctionnalités rapides et "instantanées" en restaurant les pods à partir d'un état préconfiguré.

Isolation du réseau

GKE Agent Sandbox implémente une posture de sécurité réseau Refus par défaut pour tous les environnements en bac à sable. Cela garantit que le code non approuvé exécuté dans un bac à sable ne peut pas accéder par défaut aux réseaux internes non autorisés ni 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 SandboxTemplate pour fournir une sécurité précise aux charges de travail d'agent.

Accès programmatique avec des SDK

Les ingénieurs en IA peuvent consommer des ressources GKE Agent Sandbox de manière programmatique à l'aide des bibliothèques clientes fournies. Par exemple, le Python SDK fournit une interface de haut niveau qui fait abstraction des configurations SandboxClaim et SandboxTemplate sous-jacentes. Cela vous permet de créer des environnements isolés et d'interagir avec eux directement à partir de vos frameworks d'agent basés sur Python, tels que LangChain ou le SDK Vertex AI Agentic.

Limites et exigences

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

  • Version du cluster : nécessite GKE version 1.35.2-gke.1269000 ou ultérieure pour une prise en charge complète des fonctionnalités (y compris les instantanés).
  • Exigences d'infrastructure : optimisé pour des configurations de nœud spécifiques (telles que les types de machines N2) et nécessite que le contrôleur Agent Sandbox soit installé et configuré sur le cluster.
  • Environnements d'exécution d'isolation : bien qu'il soit compatible avec plusieurs environnements d'exécution, il est principalement destiné à être utilisé avec des environnements d'exécution renforcés en matière de sécurité, tels que gVisor.
  • Disponibilité des fonctionnalités sous-jacentes : certaines fonctionnalités sous-jacentes, telles que les instantanés de pod GKE, peuvent être en aperçu ou avoir une disponibilité régionale spécifique.

Étape suivante