L’arrivée des agents IA en production à grande échelle impose une rigueur nouvelle aux environnements d’exécution. OpenKruise Agents, un sous-projet d’OpenKruise, fournit une couche d’abstraction de charge de travail pour les « sandboxes » qui hébergent les invocations d’outils ou les interpréteurs de code. La version v0.3.0, selon openkruise.io, a introduit des améliorations majeures concernant les opérations de mise à niveau, la gouvernance multi-locataire et l’optimisation des coûts.

Ce système n’est pas un framework d’agent en soi, ni un moteur d’inférence LLM ; il s’agit plutôt de la couche de gestion des environnements isolés nécessaires pour des scénarios comme Code Interpreter ou des espaces de développement persistants, en les amenant sous l’orchestration native de Kubernetes.

Gestion des cycles de vie et optimisation des ressources

Les attentes autour des sandboxes ont évolué, passant du simple fait qu’elles « fonctionnent » à des exigences de performance, de stabilité et de maniabilité. La v0.3.0 a notamment permis une chaîne complète de mise à niveau pour les sandboxes en « warm pool » ou déjà réclamés, grâce à l’introduction des SandboxUpdateOps. Cela permet, en théorie, de faire évoluer ces environnements sans les arrêter brutalement. De plus, la possibilité d’un redimensionnement CPU en place (VPA) lors de la phase de réclamation ajoute une couche d’agilité opérationnelle.

La logique de fonctionnement repose sur des ressources définies : un SandboxSet gère le lot de sandboxes disponibles dans le warm pool, tandis qu’un SandboxClaim requiert l’utilisation d’une instance de ce pool. Ces éléments, couplés au Checkpoint qui permet de prendre des clichés d’état mémoire et système de fichiers, offrent des capacités essentielles pour la reproduction de bugs ou les rollouts en apprentissage par renforcement.

Sécurisation et contrôle réseau à l’échelle

Si la v0.3.0 réglait les questions d’évolution et de coût, les développements ultérieurs, comme la v0.6.0, s’attaquent frontalement à la sécurisation et à l’automatisation. En ajoutant un plan de données dédié, l’architecture passe de quatre composants à six, intégrant des éléments cruciaux pour le contrôle du trafic.

Ce faisant, le contrôle sort du Pod lui-même. L’accès sortant (egress) est capturé au niveau du traffic-proxy embarqué, puis traité par une passerelle centrale (egress gateway) qui applique des politiques de niveau 7 (HTTP). Ce découplage est délibéré : les rejets de niveau 4 (L4) sont bloqués localement avec une faible latence, tandis que les inspections plus fines sont centralisées, ce qui offre une traçabilité unifiée.

Les nouvelles ressources, comme TrafficPolicy et SecurityProfile, permettent de définir précisément ce qu’un sandbox peut atteindre et comment une requête spécifique doit être traitée. Par exemple, une TrafficPolicy agit comme une liste blanche ; toute sortie non autorisée est bloquée, et il est impératif, selon les détails techniques, d’inclure le service de DNS du cluster pour éviter une panne silencieuse.

Sources

• OpenKruise Agents v0.3.0: Making Agent Sandboxes Truly Operatable | OpenKruise, openkruise.io
• OpenKruise Agents v0.6.0: Leaping ahead in agent Sandbox security and automation, CNCF, 3 novembre 2026 (contenu sous licence CC BY 3.0)
• The 5 essential layers of AI agent sandboxing on Kubernetes, The New Stack, 29 octobre 2026