Pianifica un'architettura per i workload degli agenti AI su GKE

Google Kubernetes Engine (GKE) fornisce due modelli di orchestrazione per l'esecuzione di agenti AI all'interno di sandbox isolate dal kernel (utilizzando microVM Cloud Hypervisor o gVisor):

  • Agent Substrate su GKE (basato su attori, consigliato): utilizza questo modello per la maggior parte dei workload degli agenti AI, in particolare per gli agenti stateful basati su CPU che vengono sospesi e ripresi di frequente. Le sessioni degli agenti attivi (attori) condividono un pool di pod worker caldi e possono essere ripristinate da Cloud Storage in meno di un secondo.
  • Agent Sandbox su GKE (basato su pod): utilizza questo modello quando ogni agente richiede un pod Kubernetes dedicato. Scegli questa opzione per agenti o workload continuamente attivi che richiedono un PodSpec Kubernetes completo (come i sidecar), GPU o TPU, nodi Arm o cluster GKE Autopilot.

Per un riepilogo affiancato dei due modelli di orchestrazione, consulta Confronta Agent Substrate e Agent Sandbox.

Leggi questo documento per scegliere un modello di orchestrazione, un runtime di sandbox, controlli di isolamento e opzioni di archiviazione prima di eseguire il provisioning del cluster GKE. Questo documento è rivolto ad architetti di soluzioni, sviluppatori AI e amministratori e operatori di piattaforme che progettano ambienti di esecuzione per agenti AI su GKE.

Requisiti di architettura per i workload degli agenti AI su GKE

L'esecuzione dei workload degli agenti AI su GKE ti consente di posizionare ambienti di esecuzione degli agenti isolati nello stesso cluster e perimetro di rete dei servizi Kubernetes di supporto e di utilizzare GKE per il provisioning automatico dei nodi, la scalabilità burst e la gestione del ciclo di vita.

A differenza dei microservizi sempre attivi, i workload degli agenti AI hanno i seguenti requisiti di architettura:

Modello basato su attori: Agent Substrate su GKE (consigliato)

Agent Substrate su GKE è un runtime di esecuzione che disaccoppia le sessioni degli agenti (attori) dai pod Kubernetes sottostanti. Gli attori attivi condividono un pool di pod worker pre-riscaldati (risorse WorkerPool) tra i template degli attori (risorse ActorTemplate). Quando la tua applicazione sospende un attore inattivo, Agent Substrate esegue il checkpoint dello stato dell'attore in Cloud Storage e rilascia la capacità del worker in modo che altri attori possano utilizzare il nodo. Quando arriva una nuova richiesta, Agent Substrate ripristina l'attore su un worker disponibile in meno di un secondo.

Utilizza Agent Substrate come architettura predefinita per i workload degli agenti basati su CPU, inclusi i seguenti casi d'uso:

  • Agenti di programmazione interattivi: assistenti AI che eseguono comandi del terminale, creano codice e modificano file durante le conversazioni con gli sviluppatori e si sospendono tra i prompt.
  • Agenti di produttività a lunga esecuzione: assistenti in background che mantengono il contesto per giorni o settimane, trascorrendo la maggior parte del tempo in attesa di input utente'utente o trigger esterni.
  • Sandbox per codice e browser temporanei: ambienti on demand per l'esecuzione di codice generato da LLM, browser headless o chiamate allo strumento che si ripristinano in meno di un secondo e rilasciano il computing dopo l'esecuzione.

Agent Substrate richiede cluster GKE Standard (versione 1.37 o successive sia sul control plane che sui node pool) con nodi worker CPU x86. GKE Autopilot non è supportato perché l'agente del nodo Agent Substrate (atelet) viene eseguito come DaemonSet con privilegi e i pool di worker microVM richiedono la virtualizzazione nidificata o nodi bare metal. Le GPU e le TPU non sono supportate.

Identità, credenziali e traffico in uscita dalla rete

Agent Substrate esegue il provisioning di un certificato SPIFFE X.509 univoco e di un token web JSON (JWT) per ogni attore per autenticare e controllare le richieste provenienti da singole sessioni. Poiché più attori condividono i pod worker nel tempo, utilizza Workload Identity Federation for GKE a livello di pod solo per le attività dell'infrastruttura worker.

Per mantenere le chiavi API e i token al di fuori della sandbox, il gateway in uscita integrato inserisce le credenziali nelle richieste in uscita in transito. I secret vengono archiviati in oggetti Secret di Kubernetes o in Secret Manager. Quando una richiesta HTTP o HTTPS in uscita corrisponde a una regola in uscita, il gateway autentica il tunnel mTLS dell'attore e sostituisce le intestazioni segnaposto con un secret recuperato o un JWT dell'attore. Per saperne di più, consulta la documentazione open source sull'inserimento delle credenziali in uscita di Agent Substrate.

Per impostazione predefinita, Agent Substrate blocca tutto il traffico in uscita verso altri attori, il control plane di Kubernetes, il server di metadati di Compute Engine e internet. Le connessioni UDP non DNS, le connessioni TCP non elaborate arbitrarie e gli upgrade di WebSocket HTTP sono bloccati e la risoluzione DNS risolve solo i nomi host consentiti dalla risorsa EgressPolicy dell'attore. Per consentire le connessioni in uscita, definisci regole di passthrough HTTP, HTTPS o TLS nella risorsa EgressPolicy utilizzando nomi di dominio completi (FQDN) o nomi host con caratteri jolly. Gli indirizzi IP e gli intervalli CIDR non sono supportati. Per saperne di più, consulta la documentazione open source di Agent Substrate relativa al traffico in uscita e alla sicurezza.

Checkpoint delle sessioni e spazio di archiviazione del workspace

Quando l'applicazione sospende un attore (su gVisor o microVM), Agent Substrate salva uno snapshot in Cloud Storage su tre livelli: memoria attiva, modifiche al file system root e directory durevoli (il livello dei volumi). Tutti i volumi CSI esterni collegati rimangono nel relativo spazio di archiviazione di supporto al di fuori dello snapshot e vengono ricollegati al ripristino.

Quando un attore sospeso riprende, Agent Substrate ripristina il livello di snapshot più alto che corrisponde all'ambiente di destinazione:

  • Memoria, file system root e volumi: ripristinati in meno di un secondo quando l'attore riprende con lo stesso hardware, runtime della sandbox e immagine container.
  • File system e volumi root: vengono ripristinati quando l'hardware del nodo o il runtime della sandbox cambiano. L'attore riavvia i suoi processi mantenendo le modifiche al file system radice e le directory permanenti.
  • Solo volumi: vengono ripristinati quando aggiorni l'immagine container nella risorsa ActorTemplate mentre l'attore è sospeso. Al ripristino successivo, i container vengono avviati dall'immagine aggiornata e vengono ripristinate le directory durevoli e i volumi esterni. Scrivi i dati che devono sopravvivere agli aggiornamenti delle immagini in directory permanenti o in uno spazio di archiviazione esterno.

La latenza di sospensione e ripresa varia in base alle dimensioni dello snapshot. Per workspace di grandi dimensioni che richiedono un ricollegamento rapido tra nodi quando un attore riprende su un nodo diverso, utilizza i volumi per agenti Filestore esterni anziché archiviare i dati all'interno dello snapshot. Ogni volume CSI esterno (anteprima) in una risorsa ActorTemplate viene eseguito il provisioning esclusivamente per un singolo attore (non condiviso tra gli attori) e viene eliminato con quell'attore. L'assistenza in produzione per i volumi per agenti Filestore è offerta tramite un programma GA limitato che richiede una richiesta di accesso.

L'archiviazione a blocchi (come Hyperdisk) viene utilizzata per i dischi di avvio dei nodi e la memorizzazione nella cache degli snapshot locali anziché per i volumi CSI per attore, perché la latenza di scollegamento e collegamento dei blocchi tra nodi rallenta il ripristino degli attori. Per saperne di più, consulta la documentazione open source sui volumi CSI di Agent Substrate.

Modello basato su pod: Agent Sandbox su GKE

Agent Sandbox su GKE esegue ogni agente in un pod Kubernetes stateful dedicato gestito tramite risorse personalizzate di Kubernetes (Sandbox, SandboxClaim, SandboxTemplate e SandboxWarmPool). Una risorsa SandboxWarmPool gestisce le risorse Sandbox preriscaldate con i pod in esecuzione per una risorsa SandboxTemplate specifica, in modo che il controller possa assegnare una risorsa Sandbox pronta e il relativo pod in esecuzione a una richiesta in meno di un secondo.

Scegli Agent Sandbox quando ogni agente ha bisogno di un pod dedicato o quando i tuoi workload hanno uno dei seguenti requisiti:

  • Agenti costantemente attivi e servizi con un singolo pod: workload senza periodi di inattività frequenti o sessioni persistenti (come ambienti di sviluppo cloud o Jupyter Notebook) che richiedono un nome host e uno spazio di archiviazione stabili senza la complessità di StatefulSet.
  • Acceleratori hardware (GPU o TPU): agenti che necessitano di accesso diretto alle GPU o alle TPU all'interno della sandbox. Gli acceleratori funzionano solo con il runtime gVisor sui modelli di GPU e sulle versioni di TPU supportati. Le microVM non supportano GPU o TPU.
  • PodSpec Kubernetes completo, nodi Arm o GKE Autopilot: workload che richiedono container sidecar o init personalizzati, API e strumenti Kubernetes standard (ad esempio comandi kubectl, controllo dell'accesso basato su ruoli e controller esistenti), CPU Arm o cluster GKE Autopilot.

Identità, credenziali e policy di rete

Poiché ogni agente viene eseguito in un pod dedicato, puoi concedere Google Cloud le autorizzazioni di Identity and Access Management (IAM) al pod utilizzando Workload Identity Federation for GKE o Agent Identity (anteprima). Entrambe le opzioni associano l'identità al ServiceAccount Kubernetes del pod al momento della creazione del pod, pertanto tutti i pod pre-riscaldati in una risorsa SandboxWarmPool condividono la stessa identità. Per isolare le identità per agente o tenant, mantieni una risorsa SandboxWarmPool separata per identità o crea risorse Sandbox on demand senza un pool caldo.

Puoi montare i secret nei pod utilizzando oggetti Secret Kubernetes standard o volumi CSI. Agent Sandbox non include un gateway per l'inserimento di credenziali esterne alla sandbox. Per inserire le credenziali in transito, esegui il deployment del tuo proxy esterno.

Il controller crea un oggetto NetworkPolicy default-deny per ogni risorsa SandboxTemplate. Per le risorse Sandbox che crei direttamente senza un template, crea il tuo oggetto NetworkPolicy. Puoi limitare il traffico utilizzando i controlli di rete GKE standard:

  • Livello 4: limita il traffico tra pod e IP con le policy di rete GKE (oggetti NetworkPolicy).
  • Livello 7: limita le connessioni in uscita ai domini approvati con le policy di rete FQDN (oggetti FQDNNetworkPolicy).

Sospensione per inattività, snapshot dei pod e spazio di archiviazione

Il pod di un agente inattivo mantiene la CPU e la memoria riservate finché l'applicazione non sospende la risorsa Sandbox impostando il campo spec.operatingMode su Suspended. La sospensione della risorsa Sandbox elimina il pod, ma mantiene i suoi volumi permanenti. L'eliminazione del pod cancella i dati in memoria e le modifiche al file system del container. Per salvare e ripristinare lo stato da Cloud Storage, acquisisci uno snapshot del pod GKE prima di sospendere l'agente. Gli snapshot dei pod richiedono il runtime gVisor e non supportano microVM o TPU. Il ripristino di un pod da uno snapshot richiede circa 3-5 secondi.

Per l'archiviazione permanente oltre gli snapshot dei pod, scegli tra le seguenti opzioni:

Confronta Agent Substrate e Agent Sandbox

La seguente tabella riassume le differenze di architettura tra Agent Substrate su GKE e Agent Sandbox su GKE:

Dimensioni Agent Substrate su GKE (basato su attori) Agent Sandbox su GKE (basato su pod)
Workload degli agenti AI consigliati La maggior parte degli agenti stateful basati su CPU che vengono sospesi e ripresi di frequente Agenti sempre attivi, workload GPU o TPU, PodSpec personalizzati, nodi Arm o GKE Autopilot
Unità di pianificazione Più attori condividono un pool di pod preinizializzati (WorkerPool) Un pod dedicato per agente (sandbox)
Runtime sandbox MicroVM gVisor e Cloud Hypervisor (gestite all'interno dei pod WorkerPool) gVisor e microVM su GKE Standard (con GKE Sandbox abilitato sul pool di nodi o su ComputeClass) o gVisor su GKE Autopilot (abilitato per impostazione predefinita)
Warm pooling Risorse WorkerPool condivise tra modelli di attori e immagini container Una risorsa SandboxWarmPool per template e immagine container
Percorso del control plane Control plane e database dedicati esterni al componente kube-apiserver Controller Kubernetes standard, kube-apiserver e etcd
Gestione delle risorse inattive La sospensione di un attore inattivo rilascia la CPU e la memoria del worker La sospensione di una risorsa Sandbox inattiva elimina il pod e mantiene i volumi permanenti
Checkpoint di stato Snapshot di Cloud Storage integrati su gVisor e microVM, con ripristino in meno di un secondo Snapshot dei pod GKE (supportati solo su gVisor), con ripristino in 3-5 secondi
Modalità cluster supportate GKE Standard (versione 1.37 o successive, nodi x86) GKE Standard e GKE Autopilot
Acceleratori hardware Non supportato (nodi worker solo CPU) GPU e TPU supportate solo con il runtime gVisor
Supporto di PodSpec Kubernetes Suddivisione del sottoinsieme tra le risorse ActorTemplate e WorkerPool PodSpec completo, inclusi sidecar e container init
Networking Gateway Envoy integrati in entrata e in uscita con tunnel mTLS per attore Servizi Kubernetes, NetworkPolicy e FQDNNetworkPolicy
Modello di identità Certificato X.509 SPIFFE e JWT per attore ServiceAccount del pod che utilizza Workload Identity Federation for GKE o Agent Identity (anteprima), condiviso in un pool caldo
Gestione dei secret Inserito nelle richieste in uscita nel gateway in uscita Montati nel pod utilizzando oggetti Secret di Kubernetes o volumi CSI

Seleziona un runtime di sandbox

Sia Agent Substrate che Agent Sandbox isolano il codice non attendibile dal nodo host utilizzando microVM Cloud Hypervisor o gVisor, ma il runtime viene configurato in modo diverso in ogni modello:

  • Agent Substrate: seleziona il runtime nella risorsa WorkerPool. Agent Substrate gestisce i propri runtime microVM e gVisor all'interno dei pod WorkerPool anziché utilizzare la funzionalità GKE Sandbox a livello di nodo. Non abilitare GKE Sandbox sui pool di nodi worker di Agent Substrate, perché il taint del nodo sandbox.gke.io/runtime impedisce la pianificazione dei pod WorkerPool.
  • Agent Sandbox: imposta il campo runtimeClassName su gvisor o microvm nel template del pod della risorsa SandboxTemplate. In GKE Standard, attiva anche GKE Sandbox nel pool di nodi o in una ComputeClass personalizzata. In GKE Autopilot, gVisor è disponibile per impostazione predefinita e le microVM non sono supportate.

Entrambi i runtime eseguono codice non attendibile e browser headless:

  • MicroVMs: ogni sandbox viene eseguita in una macchina virtuale leggera con un kernel Linux guest dedicato. Scegli le microVM quando hai bisogno di isolamento a livello di VM, compatibilità completa con le syscall Linux o limiti di CPU e memoria per container all'interno di un attore multi-container.
  • gVisor: ogni sandbox viene eseguita in un kernel dello spazio utente che intercetta e filtra le chiamate di sistema Linux. Scegli gVisor per cold start più rapidi, overhead di memoria inferiore o un supporto più ampio delle macchine Compute Engine (tra cui GPU, TPU, nodi Arm e GKE Autopilot in Agent Sandbox).

La seguente tabella mette a confronto le microVM e gVisor su GKE:

Funzionalità MicroVMs gVisor
Accesso al kernel Kernel Linux completo Sottoinsieme di syscall del kernel Linux
Livello di isolamento Virtualizzazione hardware con un kernel guest dedicato Intercettazione delle syscall in un kernel dello spazio utente
Overhead di CPU e memoria Memoria VMM per attore in Agent Substrate. 250 mCPU e 130 MiB fissi per pod in GKE Sandbox. Overhead dinamico con memoria di base ridotta
Ora di inizio Da 1 a 2 secondi Meno di 100 ms
Configurazione dei nodi GKE Nodi GKE Standard con virtualizzazione nidificata (entrambi i modelli) o nodi bare metal x86 (solo Agent Substrate) Pool di nodi GKE Standard (entrambi i modelli) o nodi GKE Autopilot (solo Agent Sandbox)
Supporto delle immagini dei nodi Container-Optimized OS (cos_containerd) in Agent Substrate. Container-Optimized OS (cos_containerd) o Ubuntu in GKE Sandbox. Solo Container-Optimized OS (cos_containerd)
Compatibilità del tipo di macchina Serie di macchine x86 che supportano la virtualizzazione nidificata e x86 bare metal (non supportata su E2 o Arm) Serie x86 con CPU non mista in Agent Substrate. La maggior parte delle serie x86, Arm e di acceleratori in Agent Sandbox.
Supporto degli acceleratori Non supportata Modelli di GPU e versioni di TPU supportati (solo Agent Sandbox)
Esempi di casi d'uso
  • Agenti di programmazione e browser autonomi
  • Workload che richiedono la compatibilità completa con il kernel Linux
  • Workload con I/O elevato e chiamate di sistema frequenti
  • Applicazioni non attendibili in Python, Node.js, Go, Java o Rust
  • Sandbox per l'inferenza e l'esecuzione di codice su CPU, GPU o TPU
  • Frontend, cache e proxy web

Per saperne di più su queste tecnologie di isolamento, consulta GKE Sandbox.

Passaggi successivi