Planifier une architecture pour les charges de travail d'agents IA sur GKE

Google Kubernetes Engine (GKE) propose deux modèles d'orchestration pour exécuter des agents IA dans des bacs à sable isolés du noyau (à l'aide de microVM Cloud Hypervisor ou de gVisor) :

  • Agent Substrate sur GKE (basé sur les acteurs, recommandé) : utilisez ce modèle pour la plupart des charges de travail d'agents IA, en particulier les agents avec état basés sur le processeur qui se suspendent et reprennent fréquemment. Les sessions d'agent actives (acteurs) partagent un pool de pods de nœuds de calcul actifs et peuvent être restaurées à partir de Cloud Storage en moins d'une seconde.
  • Agent Sandbox sur GKE (basé sur des pods) : utilisez ce modèle lorsque chaque agent nécessite un pod Kubernetes dédié. Choisissez cette option pour les agents ou les charges de travail actifs en continu qui nécessitent une spécification PodSpec Kubernetes complète (comme les side-cars), des GPU ou des TPU, des nœuds Arm ou des clusters GKE Autopilot.

Pour obtenir un récapitulatif comparatif des deux modèles d'orchestration, consultez Comparer Agent Substrate et Agent Sandbox.

Lisez ce document pour choisir un modèle d'orchestration, un environnement d'exécution de bac à sable, des contrôles d'isolation et des options de stockage avant de provisionner votre cluster GKE. Ce document s'adresse aux architectes de solutions, aux développeurs d'IA, ainsi qu'aux administrateurs et opérateurs de plates-formes qui conçoivent des environnements d'exécution pour les agents IA sur GKE.

Exigences architecturales pour les charges de travail d'agent IA sur GKE

L'exécution de charges de travail d'agents IA sur GKE vous permet de placer des environnements d'exécution d'agents isolés dans le même cluster et le même périmètre réseau que vos services Kubernetes compatibles, et d'utiliser GKE pour le provisionnement automatique des nœuds, le scaling en rafale et la gestion du cycle de vie.

Contrairement aux microservices actifs en continu, les charges de travail des agents IA ont les exigences architecturales suivantes :

Modèle basé sur les acteurs : Agent Substrate sur GKE (recommandé)

Agent Substrate sur GKE est un environnement d'exécution qui dissocie les sessions d'agent (acteurs) des pods Kubernetes sous-jacents. Les acteurs actifs partagent un pool de pods de nœuds de calcul préchauffés (ressources WorkerPool) entre les modèles d'acteur (ressources ActorTemplate). Lorsque votre application suspend un acteur inactif, Agent Substrate crée un point de contrôle de l'état de l'acteur dans Cloud Storage et libère sa capacité de nœud de calcul afin que d'autres acteurs puissent utiliser le nœud. Lorsqu'une nouvelle requête arrive, Agent Substrate restaure l'acteur sur un nœud de calcul disponible en moins d'une seconde.

Utilisez Agent Substrate comme architecture par défaut pour les charges de travail d'agent basées sur le processeur, y compris dans les cas d'utilisation suivants :

  • Agents de codage interactifs : assistants IA qui exécutent des commandes de terminal, créent du code et modifient des fichiers pendant les conversations des développeurs, et se suspendent entre les requêtes.
  • Agents de productivité de longue durée : assistants en arrière-plan qui conservent le contexte pendant des jours ou des semaines, tout en passant la majeure partie de leur temps à attendre une entrée utilisateur ou des déclencheurs externes.
  • Bacs à sable de code et de navigateur éphémères : environnements à la demande pour exécuter du code généré par LLM, des navigateurs sans interface graphique ou des appels d'outils qui se restaurent en moins d'une seconde et libèrent les ressources de calcul après l'exécution.

Agent Substrate nécessite des clusters GKE Standard (version 1.37 ou ultérieure sur le plan de contrôle et les pools de nœuds) avec des nœuds de calcul de processeur x86. GKE Autopilot n'est pas compatible, car l'agent de nœud Agent Substrate (atelet) s'exécute en tant que DaemonSet privilégié, et les pools de nœuds de calcul microVM nécessitent une virtualisation imbriquée ou des nœuds bare metal. Les GPU et les TPU ne sont pas compatibles.

Identité, identifiants et sortie réseau

Agent Substrate provisionne un certificat SPIFFE X.509 et un jeton Web JSON (JWT) uniques pour chaque acteur afin d'authentifier et d'auditer les requêtes des sessions individuelles. Étant donné que plusieurs acteurs partagent des pods de nœuds de calcul au fil du temps, n'utilisez la fédération d'identité de charge de travail pour GKE au niveau du pod que pour les tâches d'infrastructure des nœuds de calcul.

Pour conserver les clés API et les jetons en dehors du bac à sable, la passerelle de sortie intégrée injecte des identifiants dans les requêtes sortantes en transit. Vous stockez les secrets dans des objets Secret Kubernetes ou dans Secret Manager. Lorsqu'une requête HTTP ou HTTPS sortante correspond à une règle de sortie, la passerelle authentifie le tunnel mTLS de l'acteur et remplace les en-têtes d'espace réservé par un secret récupéré ou un jeton JWT d'acteur. Pour en savoir plus, consultez la documentation sur l'injection d'identifiants de sortie Agent Substrate Open Source.

Par défaut, Agent Substrate bloque tout le trafic sortant vers d'autres acteurs, le plan de contrôle Kubernetes, le serveur de métadonnées Compute Engine et Internet. Les connexions UDP non DNS, les connexions TCP brutes arbitraires et les mises à niveau HTTP WebSocket sont bloquées, et le DNS ne résout que les noms d'hôte autorisés par la ressource EgressPolicy de l'acteur. Pour autoriser les connexions sortantes, définissez des règles de passthrough HTTP, HTTPS ou TLS dans la ressource EgressPolicy à l'aide de noms de domaine complets (FQDN) ou de noms d'hôte génériques. Les adresses IP et les plages CIDR ne sont pas acceptées. Pour en savoir plus, consultez la documentation Open Source sur le trafic de sortie et la sécurité d'Agent Substrate.

Points de contrôle de session et stockage de l'espace de travail

Lorsque votre application suspend un acteur (sur gVisor ou sur des microVM), Agent Substrate enregistre un instantané dans Cloud Storage sur trois couches : la mémoire active, les modifications du système de fichiers racine et les répertoires durables (la couche des volumes). Tous les volumes CSI externes associés sont conservés sur leur espace de stockage de sauvegarde en dehors de l'instantané et sont réassociés lors de la reprise.

Lorsqu'un acteur suspendu reprend, Agent Substrate restaure la couche d'instantané la plus élevée qui correspond à l'environnement cible :

  • Mémoire, système de fichiers racine et volumes : restaurés en moins d'une seconde lorsque l'acteur reprend avec le même matériel, le même environnement d'exécution de bac à sable et la même image de conteneur.
  • Système de fichiers racine et volumes : restaurés lorsque le matériel du nœud ou l'environnement d'exécution du bac à sable change. L'acteur redémarre ses processus tout en conservant les modifications du système de fichiers racine et les répertoires durables.
  • Volumes uniquement : restaurés lorsque vous mettez à jour l'image de conteneur dans la ressource ActorTemplate pendant que l'acteur est suspendu. La reprise suivante démarre les conteneurs à partir de l'image mise à jour et restaure les répertoires durables et les volumes externes. Écrivez les données qui doivent survivre aux mises à jour d'images dans des répertoires durables ou un espace de stockage externe.

La latence de suspension et de reprise évolue en fonction de la taille de l'instantané. Pour les grands espaces de travail qui nécessitent un rattachement rapide entre les nœuds lorsqu'un acteur reprend sur un autre nœud, utilisez des volumes d'agent Filestore externes plutôt que de stocker les données dans l'instantané. Chaque volume CSI externe (preview) d'une ressource ActorTemplate est provisionné exclusivement pour un seul acteur (non partagé entre les acteurs) et est supprimé avec cet acteur. La compatibilité en production des volumes d'agent Filestore est proposée via un programme de disponibilité générale limité qui nécessite une demande d'accès.

Le stockage de blocs (comme Hyperdisk) est utilisé pour les disques de démarrage des nœuds et la mise en cache des instantanés locaux plutôt que pour les volumes CSI par acteur, car la latence d'association et de dissociation des blocs entre les nœuds ralentit la reprise des acteurs. Pour en savoir plus, consultez la documentation Open Source sur les volumes CSI Agent Substrate.

Modèle basé sur les pods : Agent Sandbox sur GKE

Agent Sandbox sur GKE exécute chaque agent dans un pod Kubernetes avec état dédié, géré via des ressources personnalisées Kubernetes (Sandbox, SandboxClaim, SandboxTemplate et SandboxWarmPool). Une ressource SandboxWarmPool gère les ressources Sandbox préchauffées avec des pods en cours d'exécution pour une ressource SandboxTemplate spécifique, de sorte que le contrôleur puisse attribuer une ressource Sandbox prête et son pod en cours d'exécution à une revendication en moins d'une seconde.

Choisissez Agent Sandbox lorsque chaque agent a besoin d'un pod dédié ou lorsque vos charges de travail présentent l'une des exigences suivantes :

  • Agents actifs en continu et services à un seul pod : charges de travail sans périodes d'inactivité fréquentes, ou sessions persistantes (comme les environnements de développement cloud ou les notebooks Jupyter) qui nécessitent un nom d'hôte et un stockage stables sans la complexité de StatefulSet.
  • Accélérateurs matériels (GPU ou TPU) : agents qui ont besoin d'un accès direct aux GPU ou TPU dans le bac à sable. Les accélérateurs ne fonctionnent qu'avec l'environnement d'exécution gVisor sur les modèles de GPU et les versions de TPU compatibles. Les microVM ne sont pas compatibles avec les GPU ni les TPU.
  • PodSpec Kubernetes complet, nœuds Arm ou GKE Autopilot : charges de travail nécessitant des conteneurs side-car ou d'initialisation personnalisés, des API et des outils Kubernetes standards (par exemple, des commandes kubectl, un contrôle des accès basé sur les rôles et des contrôleurs existants), des processeurs Arm ou des clusters GKE Autopilot.

Identité, identifiants et règles de réseau

Étant donné que chaque agent s'exécute dans un pod dédié, vous pouvez accorder des autorisations Google CloudIdentity and Access Management (IAM) au pod à l'aide de Workload Identity Federation for GKE ou de l'Agent Identity (preview). Les deux options lient l'identité au compte de service Kubernetes du pod lors de la création du pod. Ainsi, tous les pods préchauffés d'une ressource SandboxWarmPool partagent la même identité. Pour isoler les identités par agent ou par locataire, gérez une ressource SandboxWarmPool distincte par identité ou créez des ressources Sandbox à la demande sans pool de préchauffage.

Vous installez des secrets dans des pods à l'aide d'objets Secret Kubernetes standards ou de volumes CSI. Agent Sandbox n'inclut pas de passerelle pour l'injection d'identifiants hors du bac à sable. Pour injecter des identifiants en transit, déployez votre propre proxy externe.

Le contrôleur crée un objet NetworkPolicy de refus par défaut pour chaque ressource SandboxTemplate. Pour les ressources de bac à sable que vous créez directement sans modèle, créez votre propre objet NetworkPolicy. Vous limitez le trafic à l'aide des contrôles réseau GKE standards :

  • Couche 4 : limitez le trafic entre pods et le trafic IP avec les règles de réseau GKE (objets NetworkPolicy).
  • Couche 7 : limitez les connexions sortantes aux domaines approuvés avec des règles de réseau FQDN (objets FQDNNetworkPolicy).

Suspension en cas d'inactivité, instantanés de pods et stockage

Le pod d'un agent inactif conserve son processeur et sa mémoire réservés jusqu'à ce que votre application suspende la ressource Sandbox en définissant son champ spec.operatingMode sur Suspended. La suspension de la ressource Sandbox supprime le pod tout en conservant ses volumes persistants. La suppression du pod efface les données en mémoire et les modifications apportées au système de fichiers du conteneur. Pour enregistrer et restaurer cet état à partir de Cloud Storage, prenez un instantané de pod GKE avant de suspendre l'agent. Les instantanés de pods nécessitent l'environnement d'exécution gVisor et ne sont pas compatibles avec les microVM ni les TPU. La restauration d'un pod à partir d'un instantané prend environ trois à cinq secondes.

Pour un stockage persistant au-delà des instantanés de pods, choisissez l'une des options suivantes :

Comparer Agent Substrate et Agent Sandbox

Le tableau suivant récapitule les différences d'architecture entre Agent Substrate sur GKE et Agent Sandbox sur GKE :

Dimension Agent Substrate sur GKE (basé sur les acteurs) Agent Sandbox sur GKE (basé sur des pods)
Charges de travail d'agent IA recommandées La plupart des agents avec état basés sur le processeur qui sont fréquemment suspendus et réactivés Agents actifs en continu, charges de travail GPU ou TPU, PodSpecs personnalisés, nœuds Arm ou GKE Autopilot
Unité de planification Plusieurs acteurs partagent un pool de pods préprovisionnés (WorkerPool) Un pod dédié par agent (Sandbox)
Environnements d'exécution de bac à sable Micro-VM gVisor et Cloud Hypervisor (gérées dans les pods WorkerPool) gVisor et microVM sur GKE Standard (avec GKE Sandbox activé sur le pool de nœuds ou la ComputeClass), ou gVisor sur GKE Autopilot (activé par défaut)
Warm pooling Ressources WorkerPool partagées entre les modèles d'acteur et les images de conteneur Une ressource SandboxWarmPool par modèle et image de conteneur
Chemin du plan de contrôle Plan de contrôle et base de données dédiés en dehors du composant kube-apiserver Contrôleurs Kubernetes standards, kube-apiserver et etcd
Gestion des ressources inactives La suspension d'un acteur inactif libère le processeur et la mémoire de son nœud de calcul La suspension d'une ressource Sandbox inactive supprime son pod et conserve les volumes persistants
Points de contrôle d'état Instant de Cloud Storage intégré sur gVisor et les microVM, restauration en moins d'une seconde Instantanés de pods GKE (compatibles avec gVisor uniquement), restauration en 3 à 5 secondes
Modes de cluster compatibles GKE Standard (version 1.37 ou ultérieure, nœuds x86) GKE Standard et GKE Autopilot
Accélérateurs matériels Non compatible (nœuds de calcul CPU uniquement) GPU et TPU compatibles avec l'environnement d'exécution gVisor uniquement
Compatibilité avec Kubernetes PodSpec Sous-ensemble réparti entre les ressources ActorTemplate et WorkerPool PodSpec complet, y compris les side-cars et les conteneurs d'initialisation
Mise en réseau Passerelles d'entrée et de sortie Envoy intégrées avec des tunnels mTLS par acteur Services Kubernetes, NetworkPolicy et FQDNNetworkPolicy
Modèle d'identité Certificat SPIFFE X.509 et jeton JWT par acteur ServiceAccount de pod utilisant la fédération d'identité de charge de travail pour GKE ou l'identité de l'agent (preview), partagé entre un pool de préchauffage
Gestion des secrets Injecté dans les requêtes sortantes au niveau de la passerelle de sortie Montés dans le pod à l'aide d'objets Secret Kubernetes ou de volumes CSI

Sélectionner un environnement d'exécution de bac à sable

Agent Substrate et Agent Sandbox isolent tous deux le code non fiable du nœud hôte à l'aide de microVM Cloud Hypervisor ou de gVisor, mais vous configurez l'environnement d'exécution différemment dans chaque modèle :

  • Agent Substrate : sélectionnez l'environnement d'exécution sur la ressource WorkerPool. Agent Substrate gère ses propres environnements d'exécution microVM et gVisor dans ses pods WorkerPool plutôt que d'utiliser la fonctionnalité GKE Sandbox au niveau du nœud. N'activez pas GKE Sandbox sur les pools de nœuds de calcul Agent Substrate, car le rejet de nœud sandbox.gke.io/runtime empêche la planification des pods WorkerPool.
  • Agent Sandbox : définissez le champ runtimeClassName sur gvisor ou microvm dans le modèle de pod de votre ressource SandboxTemplate. Sur GKE Standard, activez également GKE Sandbox sur le pool de nœuds ou dans une ComputeClass personnalisée. Sur GKE Autopilot, gVisor est disponible par défaut et les microVM ne sont pas compatibles.

Les deux environnements d'exécution exécutent du code non approuvé et des navigateurs headless :

  • MicroVMs : chaque bac à sable s'exécute dans une machine virtuelle légère avec un noyau Linux invité dédié. Choisissez des microVM lorsque vous avez besoin d'une isolation au niveau de la VM, d'une compatibilité totale avec les appels système Linux ou de limites de processeur et de mémoire par conteneur dans un acteur multiconteneur.
  • gVisor : chaque bac à sable s'exécute dans un noyau d'espace utilisateur qui intercepte et filtre les appels système Linux. Choisissez gVisor pour des démarrages à froid plus rapides, une surcharge de mémoire plus faible ou une compatibilité plus étendue avec les machines Compute Engine (y compris les GPU, les TPU, les nœuds Arm et GKE Autopilot dans Agent Sandbox).

Le tableau suivant compare les microVM et gVisor sur GKE :

Fonctionnalité MicroVMs gVisor
Accès au kernel Noyau Linux complet Sous-ensemble d'appels système du noyau Linux
Niveau d'isolement Virtualisation matérielle avec un noyau invité dédié Interception des appels système dans un noyau d'espace utilisateur
Ressources nécessaires en mémoire et en processeur Mémoire VMM par acteur dans Agent Substrate. Correction de 250 mCPU et 130 Mio par pod dans GKE Sandbox. Frais généraux dynamiques avec une mémoire de base faible
Heure de début De 1 à 2 secondes Moins de 100 ms
Configuration des nœuds GKE Nœuds GKE Standard avec virtualisation imbriquée (les deux modèles) ou nœuds Bare Metal x86 (Agent Substrate uniquement) Pools de nœuds GKE Standard (les deux modèles) ou nœuds GKE Autopilot (Agent Sandbox uniquement)
Compatibilité avec les images de nœuds Container-Optimized OS (cos_containerd) dans Agent Substrate. Container-Optimized OS (cos_containerd) ou Ubuntu dans GKE Sandbox. Container-Optimized OS (cos_containerd) uniquement
Compatibilité des types de machines Séries de machines x86 compatibles avec la virtualisation imbriquée et Bare Metal x86 (non compatible avec E2 ou Arm) Séries x86 sans CPU mixtes dans Agent Substrate. La plupart des séries x86, Arm et d'accélérateurs dans Agent Sandbox.
Compatibilité avec les accélérateurs Non compatible Modèles de GPU et versions de TPU compatibles (Agent Sandbox uniquement)
Exemples de cas d'utilisation
  • Agents de codage et de navigation autonomes
  • Charges de travail nécessitant une compatibilité totale avec le noyau Linux
  • Charges de travail à E/S élevées avec des appels système fréquents
  • Applications non fiables en Python, Node.js, Go, Java ou Rust
  • Inférence CPU, GPU ou TPU et bacs à sable d'exécution de code
  • Interfaces, caches et proxys Web

Pour en savoir plus sur ces technologies d'isolation, consultez GKE Sandbox.

Étapes suivantes