À propos d'Agent Substrate sur GKE

Agent Substrate sur GKE exécute des charges de travail agentiques à grande échelle sur des clusters Kubernetes. Il résout un problème courant d'inefficacité des ressources : les agents interactifs (comme les assistants personnels et les agents de codage) passent souvent la majeure partie de leur temps à attendre une entrée utilisateur ou des déclencheurs externes. L'exécution continue de ces agents inactifs utilise des ressources de processeur et de mémoire qui pourraient autrement être allouées à des charges de travail actives.

Agent Substrate sur GKE résout ce problème en suspendant les agents inactifs et en prenant un instantané de la mémoire active (RAM) et des fichiers locaux de l'agent. Lorsque l'agent suspendu doit agir à nouveau, le système restaure l'état de l'agent sur un bac à sable disponible en moins d'une seconde.

Agent Substrate sur GKE s'appuie sur les fonctionnalités d'Agent Sandbox sur GKE et les améliore en contournant les goulots d'étranglement du plan de contrôle Kubernetes standard. Par conséquent, il exécute beaucoup plus d'agents simultanés par machine et réduit considérablement les temps de démarrage des agents.

Les déploiements Kubernetes standards (y compris Agent Sandbox sur GKE) associent chaque charge de travail d'agent à un pod dédié. Bien que Kubernetes soit hautement évolutif, il est limité par le débit de planification et la latence de démarrage des pods. De plus, Kubernetes n'est pas compatible avec la mise en veille prolongée des pods, et le fait de conserver des millions d'agents inactifs dans un cluster épuiserait les limites de pods et la mémoire du plan de contrôle. Pour éviter de payer pour des ressources de calcul inactives, vous devez arrêter les pods et gérer l'état de l'agent dans un espace de stockage externe. Agent Substrate sur GKE résout ces contraintes de scaling en dissociant l'état de l'agent des pods sous-jacents : il stocke des millions d'instantanés d'agents suspendus dans l'espace de stockage et les restaure à la demande sur un pool partagé de nœuds de calcul actifs.

Agent Substrate sur GKE est un système Open Source que vous déployez directement sur vos propres clusters GKE Standard. Bien que le projet principal soit développé dans le dépôt Agent Substrate Open Source, Google fournit des outils et des scripts de déploiement optimisés pour GKE dans le dépôt substrate-gke pour les clients Google Cloud éligibles.

Avantages d'Agent Substrate sur GKE

Vous pouvez utiliser Agent Substrate sur GKE pour atteindre les objectifs suivants :

  • Exécuter du code non fiable de manière sécurisée : Agent Substrate sur GKE applique l'isolation du noyau et du réseau pour que vous puissiez exécuter du code généré par l'IA sans risquer de compromettre votre infrastructure globale.
  • Créer des agents de longue durée avec état : la mémoire de travail et les fichiers d'un agent sont conservés d'une session à l'autre. L'agent reprend exactement là où il s'est arrêté.
  • Répondre aux requêtes en temps réel : lorsqu'une nouvelle requête déclenche un agent suspendu, le système restaure l'état de l'agent en une fraction de seconde.
  • Réduire les coûts de calcul : vous pouvez exécuter davantage d'agents sur moins de machines en partageant un pool de bacs à sable de nœuds de calcul entre tous vos agents. Étant donné que les agents inactifs sont suspendus et n'utilisent pas de processeur ni de mémoire, vous ne payez pour le calcul que lorsque les agents traitent activement des tâches.

Cas d'utilisation

Agent Substrate sur GKE est conçu pour exécuter des agents à n'importe quelle échelle, de quelques dizaines à des millions d'agents simultanés. Voici trois exemples de charges de travail :

  • Agents de productivité : assistants en arrière-plan à long terme qui conservent le contexte pendant plusieurs semaines. Étant donné que ces assistants passent la majeure partie de leur temps à attendre des déclencheurs, la suspension des charges de travail lorsqu'elles ne sont pas utilisées réduit les coûts de calcul.
  • Bacs à sable éphémères : environnements isolés à la demande pour exécuter du code non fiable généré par un LLM, exécuter des appels d'outils ou analyser des données. Étant donné que les bacs à sable se restaurent en moins d'une seconde, le système peut fournir des environnements jetables pour les tâches de courte durée et libérer des ressources une fois l'exécution terminée.
  • Agents de codage : assistants IA qui discutent en temps réel avec les développeurs pour écrire, créer et tester du code. L'agent exécute des commandes de terminal et modifie des fichiers dans un bac à sable. Lorsque l'agent est inactif, le système le suspend jusqu'à ce que le développeur envoie une autre requête.

Fonctionnement d'Agent Substrate sur GKE

Agent Substrate sur GKE est basé sur Kubernetes, mais vous n'avez pas besoin de comprendre Kubernetes pour l'utiliser. Voici les concepts fondamentaux d'Agent Substrate sur GKE :

  • Acteur : instance unique d'un agent en cours d'exécution.
  • ActorTemplate : plan de configuration (définissant les images de conteneur, les variables d'environnement et les ressources de calcul) utilisé pour instancier les acteurs.
  • Worker : bac à sable sécurisé dans lequel un acteur actif s'exécute.
  • WorkerPool : groupe de nœuds de calcul inactifs pré-démarrés qui sont prêts à recevoir un acteur.

Comme un acteur n'est pas lié à un nœud de calcul spécifique, le système peut suspendre les agents inactifs et réutiliser les ressources de calcul libérées. Cette architecture permet au système d'exécuter des millions d'agents sur un nombre limité de machines.

Le cycle de vie d'un agent type se déroule comme suit :

  1. Routage : chaque requête API entrante provenant de votre application spécifie son acteur cible. Par exemple, lorsqu'un utilisateur saisit un nouveau prompt dans une interface de chat, votre application envoie une requête adressée à l'acteur spécifique qui gère la session de l'utilisateur.
  2. Reprise : si la requête concerne un acteur suspendu, le système demande un nœud de calcul chaud au WorkerPool et restaure l'instantané de l'acteur sur ce nœud de calcul.
  3. Exécution : le système achemine la requête vers ce nouveau nœud de calcul actif, et l'acteur traite la tâche.
  4. Suspension : lorsque l'acteur termine son travail et devient inactif, le système prend un nouvel instantané de la mémoire et des fichiers de l'acteur, l'enregistre dans l'espace de stockage et renvoie le nœud de calcul vide au pool.

Isolation des charges de travail et GKE Sandbox

Agent Substrate sur GKE utilise gVisor ou Cloud Hypervisor pour exécuter chaque charge de travail dans un bac à sable qui isole le code de l'application du noyau hôte. L'installation d'Agent Substrate sur GKE inclut un environnement d'exécution gVisor pour les nœuds de calcul. Vous n'avez donc pas besoin de configurer GKE Sandbox sur les nœuds GKE sous-jacents.

Limites et exigences

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

  • Version du cluster et API bêta : Agent Substrate sur GKE est compatible avec les clusters GKE Standard exécutant la version 1.36 (avec les options bêta activées) ou la version 1.37 ou ultérieure. Les versions antérieures à la version 1.36 ne sont pas compatibles. De plus, GKE nécessite des API bêta (podcertificaterequests et clustertrustbundles). Si vous activez ces API sur un cluster existant exécutant la version 1.36, vous devez également remplacer les nœuds existants afin que la projection de certificats de pod soit activée sur ceux-ci. Sur la version 1.37 ou ultérieure, il n'est pas nécessaire de remplacer les nœuds existants.
  • Workload Identity Federation for GKE : la Workload Identity Federation for GKE doit être activée sur les clusters GKE. Agent Substrate sur GKE utilise Workload Identity Federation for GKE pour s'authentifier auprès des API Google Cloud , telles que Cloud Storage pour enregistrer des instantanés d'agent.
  • Familles de VM :
    • Architectures de processeur mixtes : Agent Substrate sur GKE n'est pas compatible avec les séries de machines à usage général qui s'exécutent sur des architectures de processeur mixtes (comme les types de machines E2) en raison d'un problème connu avec gVisor.
    • Types de VM uniformes par modèle d'acteur : il n'est pas possible de combiner des types de VM au sein d'un même ActorTemplate (le modèle de configuration utilisé pour créer des acteurs). Par exemple, si votre cluster comporte deux pools de nœuds utilisant des VM C4 et N2, un ActorTemplate doit inclure un sélecteur de nœud qui spécifie un seul type de VM (tel que C4) pour éviter que les acteurs de ce modèle ne soient répartis sur différents types de machines.
  • Compatibilité avec les GPU : le passthrough des appareils GPU dans les conteneurs Actor n'est pas compatible. La spécification de nvidia.com/gpu ne place les pods que sur des nœuds compatibles avec les GPU, mais ne transmet pas l'appareil GPU au conteneur Actor. De plus, gVisor ne peut pas créer d'instantanés des contextes CUDA actifs.
  • Mise en réseau :
    • Règles de sortie : les règles EgressPolicy (contrôles réseau par nom d'hôte et adresse IP) ne sont pas acceptées, y compris les fonctionnalités suivantes :
      • Règles de refus par défaut
      • Règles basées sur le nom d'hôte
      • Injection d'identifiants
    • Connexions ouvertes : les connexions réseau ouvertes (telles que les sessions de base de données ou les connexions aux serveurs MCP) ne sont pas conservées lorsqu'un agent est suspendu. Le code de votre agent doit gérer la reconnexion aux services externes lorsque l'agent reprend.
  • Observabilité et OpenTelemetry géré : OpenTelemetry géré pour GKE présente les limites suivantes :
    • Les connecteurs de collecteur ne sont pas compatibles, ce qui nécessite l'utilisation d'un compteur proxy externe pour l'analyse comparative de la télémétrie.
    • Les déploiements de collecteurs entraînent une surcharge de cache de la mémoire qui évolue de manière linéaire avec le nombre de pods dans les grands clusters.
    • TLS n'est pas compatible avec OpenTelemetry géré pour GKE.
  • Stockage : le système nécessite Cloud Storage pour enregistrer les instantanés de vos agents.
  • Environnement d'installation : vous ne pouvez pas installer Agent Substrate sur GKE dans Cloud Shell. Cloud Shell est limité à 5 Go d'espace de stockage sur disque persistant, ce qui ne fournit pas assez d'espace disque pour l'installation. Vous devez installer Agent Substrate sur GKE à partir d'un poste de travail local ou d'une machine virtuelle (VM) disposant d'un espace disque suffisant.

Étapes suivantes