Informazioni sulla sandbox dell'agente su GKE

Agent Sandbox su Google Kubernetes Engine (GKE) ti aiuta a eseguire workload degli agenti isolati in pod Kubernetes dedicati. L'isolamento è importante quando gli agenti AI eseguono codice non attendibile generato da LLM. Per la maggior parte dei workload degli agenti, ti consigliamo di utilizzare Agent Substrate su GKE, perché può eseguire più agenti sugli stessi nodi. Utilizza Agent Sandbox su GKE quando ogni agente ha bisogno di un pod, di GPU o TPU dedicati, di un PodSpec Kubernetes completo o di un cluster GKE Autopilot. Per confrontare Agent Sandbox su GKE con Agent Substrate su GKE e scegliere un'architettura per i workload degli agenti AI, consulta Pianifica un'architettura per i workload degli agenti AI su GKE.

Agent Sandbox è un progetto open source di Kubernetes SIG Apps. Per utilizzare Agent Sandbox su GKE, installa il controller Agent Sandbox sul tuo cluster. Sei responsabile dell'upgrade del controller. Per istruzioni, consulta Installa Agent Sandbox su GKE.

Questo documento fornisce una panoramica concettuale di Agent Sandbox su GKE.

Perché utilizzare Agent Sandbox su GKE

Agent Sandbox su GKE fornisce a ogni agente un pod dedicato, isolato a livello di kernel, che gestisci con le API Kubernetes standard. I vantaggi principali includono:

  • Isolamento a livello di kernel: isola il codice non attendibile generato dall'LLM dal kernel del nodo utilizzando GKE Sandbox con gVisor o microVM. Agent Sandbox su GKE funziona anche con i Kata Containers open source autogestiti che installi sui nodi anziché con GKE Sandbox. Per un tutorial sull'utilizzo di Kata Containers open source con Agent Sandbox su GKE, consulta Abilitazione di Kata Containers su GKE.

  • Provisioning in meno di un secondo: fornisce pod pre-riscaldati per i tuoi agenti, in genere in meno di un secondo, invece di attendere la pianificazione e l'avvio standard dei pod Kubernetes.

  • Estendibilità cloud-native: sfrutta la potenza del paradigma Kubernetes e l'infrastruttura gestita di GKE.

Fornendo un'API dichiarativa e standardizzata, Agent Sandbox su GKE offre un'esperienza con un singolo container che fornisce caratteristiche di isolamento e persistenza simili a quelle di una macchina virtuale (VM), basata interamente sulle primitive di Kubernetes.

Casi d'uso comuni per Agent Sandbox su GKE

Utilizza Agent Sandbox su GKE per i workload che richiedono isolamento, persistenza e un'identità stabile. Ecco alcuni esempi di casi d'uso:

  • Runtime degli agenti AI: esegui il codice non attendibile in un pod che utilizza gVisor o microVMs per isolare il codice dal kernel del nodo.
  • Ambienti di sviluppo: forniscono agli sviluppatori ambienti di programmazione basati su cloud isolati e persistenti.
  • Notebook e strumenti di ricerca: ospita sessioni con un singolo container per strumenti interattivi come i notebook Jupyter.
  • Servizi stateful con un singolo pod: esegui applicazioni che richiedono un'identità e uno spazio di archiviazione stabili senza la complessità di uno StatefulSet.
  • Gestione programmatica dell'ambiente: utilizza gli SDK delle librerie client forniti, come l'SDK Python di Agent Sandbox, per richiedere e gestire le risorse della sandbox direttamente dalla logica dell'applicazione senza gestire il codice YAML di Kubernetes.

Come funziona Agent Sandbox su GKE

Agent Sandbox su GKE utilizza un controller personalizzato e diverse definizioni di risorse personalizzate (CRD) di Kubernetes per gestire il ciclo di vita delle risorse Sandbox.

Architettura di base

  • Risorsa personalizzata Sandbox: la risorsa principale che rappresenta un singolo pod stateful. La risorsa gestisce nomi host, identità di rete e archiviazione permanente stabili. Per sospendere un agente inattivo, imposta il campo spec.operatingMode della relativa risorsa Sandbox su Suspended. Il controller elimina il pod, ma mantiene la risorsa Sandbox e i relativi volumi permanenti. I dati in memoria e le modifiche al file system del container vengono persi, a meno che tu non acquisisca prima uno snapshot del pod. Per riprendere l'agente, imposta nuovamente il campo su Running. Agent Sandbox su GKE non rileva gli agenti inattivi; è la tua applicazione a decidere quando sospenderli.
  • Router sandbox: un componente che fornisce un endpoint stabile e crea un tunnel per il traffico verso i pod che eseguono gli agenti, astrando la complessità di networking sottostante.
  • Integrazione con gli snapshot dei pod: Agent Sandbox su GKE si integra con la funzionalità degli snapshot dei pod GKE per sospendere e riprendere i workload salvando e ripristinando lo stato completo di un container.

Modello di rivendicazione

Il modello di rivendicazione è una funzionalità chiave che separa la richiesta dell'utente di un ambiente dai dettagli di implementazione specifici, ad esempio dove e come viene eseguito il provisioning del workload. A differenza di uno StatefulSet Kubernetes standard, il modello di richiesta ti consente di richiedere una risorsa Sandbox senza dover gestire direttamente le configurazioni dei pod o dello spazio di archiviazione sottostanti.

Il modello di richiesta utilizza le risorse personalizzate SandboxClaim, SandboxWarmPool e SandboxTemplate e funziona come segue:

  1. Gli utenti o le applicazioni richiedono una risorsa sandbox creando una risorsa SandboxClaim che fa riferimento a una risorsa SandboxWarmPool. Il pool caldo fa riferimento alla risorsa SandboxTemplate che definisce la configurazione del pod.
  2. Il controller assegna una risorsa sandbox pronta (e il relativo pod in esecuzione) dal pool di riserva alla richiesta. Se nessuna risorsa Sandbox nel pool è pronta, il controller crea una nuova risorsa Sandbox per la richiesta dal template.

Pool preinizializzati

La funzionalità warm pool è progettata per ridurre al minimo la latenza di avvio per gli scenari di agenti AI interattivi. Utilizzando un pool caldo, Agent Sandbox su GKE può fornire ambienti di esecuzione in meno di un secondo. La funzionalità utilizza la risorsa personalizzata SandboxWarmPool e funziona come segue:

  1. Una risorsa SandboxWarmPool gestisce un pool di risorse Sandbox preinizializzate con pod in stato Pronto.
  2. Quando viene creata una risorsa SandboxClaim, il controller assegna una risorsa Sandbox pronta e il relativo pod in esecuzione dal pool, anziché attendere che un nuovo pod esegua il pull delle immagini e venga avviato.
  3. Se combinati con gli snapshot dei pod, i pool caldi possono ripristinare i pod da uno stato preconfigurato anziché avviandoli da zero.

Isolamento della rete

Agent Sandbox su GKE implementa una policy di rete di rifiuto predefinita per i pod creati dal controller da una risorsa SandboxTemplate. Per ogni risorsa SandboxTemplate, il controller crea una risorsa NetworkPolicy che aiuta a impedire al codice non attendibile all'interno del pod di accedere a reti interne non autorizzate o al control plane GKE. Puoi definire restrizioni di rete specifiche e regole per il traffico in entrata o in uscita consentito all'interno della risorsa SandboxTemplate per controllare l'accesso alla rete per i workload degli agenti.

Il controller non crea una risorsa NetworkPolicy per una risorsa Sandbox che crei direttamente. Per limitare l'accesso alla rete per i pod di queste risorse Sandbox, crea la tua risorsa NetworkPolicy.

Accesso programmatico con gli SDK

Gli ingegneri AI possono utilizzare le risorse di Agent Sandbox su GKE in modo programmatico utilizzando le librerie client fornite. Ad esempio, l'SDK Python fornisce un'interfaccia di alto livello che crea la risorsa SandboxClaim sottostante per te. La richiesta fa riferimento a una risorsa SandboxWarmPool che crei. Questa interfaccia ti consente di creare e interagire con ambienti isolati direttamente dai tuoi framework di agenti basati su Python, come LangChain o l'SDK Vertex AI Agentic.

Limitazioni e requisiti

Agent Sandbox su GKE presenta le seguenti limitazioni e requisiti:

  • Versione del cluster: Agent Sandbox su GKE viene eseguito su qualsiasi versione GKE supportata. Per utilizzare gli snapshot dei pod, il tuo cluster deve eseguire GKE 1.35.3-gke.1234000 o versioni successive.
  • Requisiti dell'infrastruttura: richiede che il controller Agent Sandbox sia installato e configurato sul cluster. Agent Sandbox su GKE non richiede un tipo di macchina specifico. Ad esempio, la guida all'installazione utilizza nodi e2-standard-2. Tuttavia, gli snapshot dei pod non supportano i tipi di macchine E2, quindi se prevedi di utilizzare gli snapshot dei pod, utilizza un'altra serie di macchine, ad esempio N2.
  • Runtime di isolamento: Agent Sandbox su GKE supporta gVisor e microVMs come runtime di isolamento. Gli snapshot dei pod richiedono gVisor e non funzionano con le microVM. Se non specifichi un runtime GKE Sandbox (gVisor o microVM), i tuoi pod vengono eseguiti senza isolamento del kernel, quindi non utilizzarli per eseguire codice non attendibile.
  • Acceleratori hardware: le GPU e le TPU funzionano solo con il runtime gVisor sui modelli di GPU e sulle versioni di TPU supportati e non sono supportate con le microVM. Inoltre, gli snapshot dei pod non supportano le TPU.
  • Disponibilità delle funzionalità di base: alcune funzionalità di base, come gli snapshot dei pod GKE, potrebbero essere in anteprima o avere una disponibilità regionale specifica.

Passaggi successivi