À 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 permettant à votre application de suspendre les agents inactifs. Lorsque votre application suspend un agent, le système prend 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 dans 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, Agent Substrate sur GKE exécute plus d'agents simultanés par machine et démarre les agents plus rapidement qu'Agent Sandbox sur GKE. Pour comparer Agent Substrate sur GKE avec Agent Sandbox 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.

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 afin 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, votre application 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 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 réutiliser les ressources de calcul qu'un acteur libère lorsque votre application le suspend. 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 nœud de calcul nouvellement actif, et l'acteur traite la tâche.
  4. Suspension : lorsque votre application suspend un acteur 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 son propre environnement d'exécution gVisor pour les nœuds de calcul. N'activez pas GKE Sandbox sur les pools de nœuds où Agent Substrate sur GKE s'exécute, car Agent Substrate sur GKE ne peut pas s'exécuter sur ces nœuds. Vous pouvez toujours utiliser GKE Sandbox pour d'autres charges de travail, y compris Agent Sandbox sur GKE.

Limites et exigences

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

  • Mode, version et canal de publication du cluster : Agent Substrate sur GKE est compatible avec les clusters GKE Standard dont le plan de contrôle et les pools de nœuds exécutent la version 1.37 ou une version ultérieure. Les clusters Autopilot et les versions antérieures à la version 1.37 ne sont pas compatibles. À partir de la version 1.37, GKE diffuse les API Kubernetes podcertificaterequests et clustertrustbundles, et permet aux nœuds d'installer des certificats de pod et des bundles de confiance dans les pods. Vous n'avez donc pas besoin d'activer vous-même les versions bêta de ces API. Toutefois, le programme d'installation active les versions bêta dans chaque cluster qu'il crée ou configure. Étant donné que le version disponible Extended n'est pas compatible avec les API bêta explicitement activées, vous ne pouvez pas utiliser le programme d'installation avec des clusters inscrits dans le version disponible Extended.

  • 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. Pour enregistrer et restaurer des instantanés, le système utilise un compte de service dédié nommé ate-snapshot-transfer. Les identifiants de chaque opération d'enregistrement ou de restauration ne peuvent accéder qu'aux instantanés d'un seul acteur. Par conséquent, vous n'avez pas besoin d'accorder à vos nœuds GKE l'accès au bucket d'instantanés. Le programme d'installation crée le compte de service ate-snapshot-transfer et lui accorde l'accès au bucket d'instantanés. Si vous configurez vous-même les autorisations, attribuez les rôles IAM suivants :

    • Sur le bucket d'instantanés, accordez au compte de service ate-snapshot-transfer et au compte de service Kubernetes ate-api-server les rôles d'administrateur des objets de l'espace de stockage (roles/storage.objectAdmin) et de lecteur des buckets de l'espace de stockage (roles/storage.bucketViewer).
    • Sur le compte de service ate-snapshot-transfer, attribuez au compte de service Kubernetes ate-api-server le rôle de créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator). Le compte de service ate-api-server emprunte l'identité du compte de service ate-snapshot-transfer pour émettre les identifiants de chaque acteur.
    • Si vous utilisez l'environnement d'exécution microVM, accordez au compte de service Kubernetes atelet le rôle Lecteur des objets Storage (roles/storage.objectViewer) sur le bucket d'éléments.

    Pour obtenir la liste complète des liaisons et des commandes gcloud équivalentes, consultez Ce que create iam accorde réellement dans le fichier README de setup-gcp.

  • 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 dans gVisor.
    • Types de VM uniformes par modèle d'acteur : tous les acteurs que vous créez à partir d'un ActorTemplate doivent s'exécuter sur le même type de VM. Un ActorTemplate n'est pas une ressource Kubernetes et ne dispose pas de sélecteur de nœud. À la place, le champ workerSelector de ActorTemplate sélectionne les ressources WorkerPool en fonction de leurs étiquettes. Chaque WorkerPool peut sélectionner les nœuds pour ses nœuds de calcul à l'aide de son champ spec.template.nodeSelector. Par exemple, si votre cluster comporte des pools de nœuds qui utilisent des VM C4 et des VM N2, configurez chaque WorkerPool pour qu'il ne sélectionne que des nœuds d'un seul type de VM. Ensuite, définissez le champ workerSelector de ActorTemplate pour qu'il ne corresponde qu'aux ressources WorkerPool qui utilisent des VM C4.
    • Virtualisation imbriquée ou Bare Metal pour les environnements d'exécution microVM : l'environnement d'exécution microVM exécute chaque bac à sable dans sa propre machine virtuelle. Les nœuds de calcul qui utilisent cet environnement d'exécution ont donc besoin de nœuds pouvant exécuter des machines virtuelles. Ces nœuds doivent utiliser l'architecture de processeur x86, et non Arm. Lorsque le programme d'installation crée un cluster, la virtualisation imbriquée est activée sur le pool de nœuds qu'il crée. Si vous installez Agent Substrate sur GKE dans un cluster existant ou si vous ajoutez vos propres pools de nœuds pour les nœuds de calcul microVM, utilisez un pool de nœuds sur lequel la virtualisation imbriquée est activée ou qui utilise un type de machine Bare Metal x86. Vous ne pouvez activer la virtualisation imbriquée que lorsque vous créez un pool de nœuds. Pour vérifier quelles séries de machines sont compatibles avec la virtualisation imbriquée, telles que C3, C4, N2 et N4, consultez Comparaison des séries 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.

  • Connexions réseau 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 : Agent Substrate sur GKE utilise les buckets Cloud Storage suivants, que le programme d'installation crée s'ils n'existent pas :

    • Bucket d'instantanés : stocke les instantanés de tous les agents de votre cluster. Ce bucket est obligatoire.
    • Bucket d'éléments : stocke les fichiers dont l'environnement d'exécution microVM a besoin, tels qu'un noyau Linux et un système de fichiers racine. L'environnement d'exécution microVM utilise ces fichiers pour exécuter chaque bac à sable dans sa propre machine virtuelle. Le nom de ce bucket est le nom du bucket d'instantanés suivi de -assets. Par exemple, si votre bucket d'instantanés s'appelle example-snapshots, le bucket d'éléments s'appelle example-snapshots-assets. Si vous n'utilisez pas l'environnement d'exécution microVM, ce bucket reste vide.

  • Paramètres du noyau pour une densité de bac à sable élevée : l'exécution de plus de 800 bacs à sable simultanés sur un nœud dépasse les limites par défaut du noyau Linux pour la surveillance du système de fichiers (inotify) et pour la table de voisinage du protocole ARP (Address Resolution Protocol). Sans limites plus élevées, les bacs à sable peuvent ne pas démarrer et la mise en réseau peut s'interrompre. Le programme d'installation applique les paramètres de noyau requis aux clusters qu'il crée. Si vous installez Agent Substrate sur GKE dans un cluster existant ou si vous ajoutez vos propres pools de nœuds, vous devez appliquer ces paramètres vous-même. Pour connaître les valeurs requises, consultez Exigences concernant les clusters et Concevoir votre infrastructure pour Agent Substrate sur GKE.

  • Environnement d'installation : vous ne pouvez pas installer Agent Substrate sur GKE dans Cloud Shell. Cloud Shell dispose d'une limite de stockage sur disque persistant de 5 Go, ce qui ne fournit pas suffisamment 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