Informazioni su Agent Substrate su GKE

Agent Substrate su GKE esegue workload agentici su larga scala su cluster Kubernetes. Risolve un'inefficienza comune delle risorse: gli agenti interattivi (come gli assistenti personali e gli agenti di programmazione) spesso trascorrono la maggior parte del tempo in attesa dell'input utente'utente o di trigger esterni. Mantenere questi agenti inattivi in esecuzione continua utilizza CPU e memoria che altrimenti potrebbero essere allocate ai workload attivi.

Agent Substrate su GKE risolve questo problema consentendo alla tua applicazione di sospendere gli agenti inattivi. Quando l'applicazione sospende un agente, il sistema acquisisce uno snapshot della memoria attiva (RAM) e dei file locali dell'agente. Quando l'agente sospeso deve agire di nuovo, il sistema ripristina lo stato dell'agente in una sandbox disponibile in meno di un secondo.

Agent Substrate su GKE si basa sulle funzionalità di Agent Sandbox su GKE e le migliora bypassando i colli di bottiglia del control plane standard di Kubernetes. Di conseguenza, Agent Substrate su GKE esegue più agenti contemporaneamente per macchina e li avvia più velocemente rispetto ad Agent Sandbox su GKE. Per confrontare Agent Substrate su GKE con Agent Sandbox su GKE e scegliere un'architettura per i workload degli agenti AI, consulta Pianifica un'architettura per i workload degli agenti AI su GKE.

I deployment Kubernetes standard (incluso Agent Sandbox su GKE) associano ogni workload dell'agente a un pod dedicato. Sebbene Kubernetes sia altamente scalabile, è limitato dal throughput di pianificazione e dalla latenza di avvio dei pod. Inoltre, Kubernetes non supporta l'ibernazione dei pod e mantenere milioni di agenti inattivi in un cluster esaurirebbe i limiti dei pod e la memoria del control plane. Per evitare di pagare per il computing inattivo, devi arrestare i pod e gestire lo stato dell'agente nello spazio di archiviazione esterno. Agent Substrate su GKE risolve questi vincoli di scalabilità disaccoppiando lo stato degli agenti dai pod sottostanti: archivia milioni di snapshot di agenti sospesi nello spazio di archiviazione e li ripristina on demand in un pool condiviso di worker attivi.

Agent Substrate su GKE è un sistema open source di cui esegui il deployment direttamente sui tuoi cluster GKE Standard. Sebbene il progetto principale sia sviluppato nel repository Agent Substrate open source, Google fornisce strumenti e script di deployment ottimizzati per GKE nel repository substrate-gke per i clienti Google Cloud idonei.

Vantaggi di Agent Substrate su GKE

Puoi utilizzare Agent Substrate su GKE per raggiungere i seguenti obiettivi:

  • Esegui codice non attendibile in sicurezza: Agent Substrate su GKE applica l'isolamento del kernel e della rete in modo da poter eseguire il codice generato dall'AI senza rischiare di compromettere l'infrastruttura più ampia.
  • Crea agenti stateful a esecuzione prolungata: la memoria di lavoro e i file di un agente vengono conservati tra le sessioni. L'agente riprende esattamente dal punto in cui è stato messo in pausa.
  • Rispondi alle richieste in tempo reale: quando una nuova richiesta attiva un agente sospeso, il sistema ripristina lo stato dell'agente in una frazione di secondo.
  • Riduzione dei costi di computing: puoi eseguire più agenti su un numero inferiore di macchine condividendo un pool di sandbox dei worker tra tutti gli agenti. Poiché gli agenti inattivi vengono sospesi e non utilizzano CPU e memoria, paghi per il computing solo quando gli agenti elaborano attivamente le attività.

Casi d'uso

Agent Substrate su GKE è progettato per eseguire agenti su qualsiasi scala, da decine a milioni di agenti contemporaneamente. Ecco tre esempi di workload:

  • Agenti di produttività: assistenti in background a lungo termine che mantengono il contesto per settimane. Poiché questi assistenti trascorrono la maggior parte del tempo in attesa di trigger, la sospensione dei workload quando non sono in uso riduce i costi di computing.
  • Sandbox temporanee: ambienti isolati on demand per l'esecuzione di codice non attendibile generato da LLM, l'esecuzione di chiamate agli strumenti o l'analisi dei dati. Poiché le sandbox vengono ripristinate in meno di un secondo, il sistema può fornire ambienti usa e getta per attività di breve durata e rilasciare risorse al termine dell'esecuzione.
  • Agenti di programmazione: assistenti AI che intrattengono conversazioni in tempo reale con gli sviluppatori per scrivere, creare e testare il codice. L'agente esegue i comandi del terminale e modifica i file all'interno di una sandbox. Quando l'agente è inattivo, l'applicazione lo sospende finché lo sviluppatore non invia un altro prompt.

Come funziona Agent Substrate su GKE

Agent Substrate su GKE è basato su Kubernetes, ma non è necessario comprendere Kubernetes per utilizzarlo. I concetti principali di Agent Substrate su GKE sono i seguenti:

  • Attore: una singola istanza in esecuzione di un agente.
  • ActorTemplate: un progetto di configurazione (che definisce immagini container, variabili di ambiente e risorse di computing) utilizzato per creare istanze di Actor.
  • Worker: una sandbox in cui viene eseguito un attore attivo.
  • WorkerPool: un gruppo di worker pre-avviati e inattivi che vengono tenuti pronti per ricevere un attore.

Poiché un attore non è legato a un worker specifico, il sistema può riutilizzare l'elaborazione che un attore libera quando l'applicazione lo sospende. Questa architettura consente al sistema di eseguire milioni di agenti su un numero limitato di macchine.

Un ciclo di vita tipico di un agente prevede i seguenti passaggi:

  1. Routing: ogni richiesta API in entrata dalla tua applicazione specifica l'attore di destinazione. Ad esempio, quando un utente digita un nuovo prompt in un'interfaccia di chat, l'applicazione invia una richiesta indirizzata all'attore specifico che gestisce la sessione dell'utente.
  2. Ripresa: se la richiesta riguarda un attore sospeso, il sistema richiede un worker caldo dal WorkerPool e ripristina lo snapshot dell'attore su quel worker.
  3. Esecuzione: il sistema indirizza la richiesta a questo worker appena attivato e l'attore elabora l'attività.
  4. Sospensione: quando l'applicazione sospende un attore inattivo, il sistema acquisisce un nuovo snapshot della memoria e dei file dell'attore, lo salva nello spazio di archiviazione e rilascia il worker vuoto nel pool.

Isolamento dei workload e GKE Sandbox

Agent Substrate su GKE utilizza gVisor o Cloud Hypervisor per eseguire ogni workload in una sandbox che isola il codice dell'applicazione dal kernel host. L'installazione di Agent Substrate su GKE include il proprio runtime gVisor per i worker. Non attivare GKE Sandbox sui node pool in cui viene eseguito Agent Substrate su GKE, perché Agent Substrate su GKE non può essere eseguito su questi nodi. Puoi comunque utilizzare GKE Sandbox per altri workload, tra cui Agent Sandbox su GKE.

Limitazioni e requisiti

Agent Substrate su GKE presenta le seguenti limitazioni e requisiti:

  • Modalità, versione e canale di rilascio del cluster: Agent Substrate su GKE supporta i cluster GKE Standard il cui control plane e i cui node pool eseguono la versione 1.37 o successive. I cluster Autopilot e le versioni precedenti alla 1.37 non sono supportati. Nella versione 1.37 e successive, GKE gestisce le API Kubernetes podcertificaterequests e clustertrustbundles e consente ai nodi di montare i certificati dei pod e i bundle di attendibilità nei pod, quindi non è necessario attivare manualmente le versioni beta di queste API. Tuttavia, il programma di installazione attiva le versioni beta in ogni cluster che crea o configura. Poiché il canale di rilascio esteso non supporta le API beta abilitate esplicitamente, non puoi utilizzare il programma di installazione con i cluster registrati nel canale di rilascio esteso.

  • Workload Identity Federation for GKE: i cluster GKE devono avere Workload Identity Federation for GKE abilitato. Agent Substrate su GKE utilizza Workload Identity Federation for GKE per l'autenticazione alle API Google Cloud , ad esempio Cloud Storage per il salvataggio degli snapshot degli agenti. Per salvare e ripristinare gli snapshot, il sistema utilizza un account di servizio dedicato denominato ate-snapshot-transfer. Le credenziali per ogni operazione di salvataggio o ripristino possono accedere solo agli snapshot di un attore. Di conseguenza, non è necessario concedere ai nodi GKE l'accesso al bucket degli snapshot. Il programma di installazione crea il account di servizio ate-snapshot-transfer e gli concede l'accesso al bucket di snapshot. Se invece configuri le autorizzazioni autonomamente, concedi i seguenti ruoli IAM:

    • Nel bucket di snapshot, concedi al service account ate-snapshot-transfer e al account di servizio Kubernetes ate-api-server i ruoli Storage Object Admin (roles/storage.objectAdmin) e Storage Bucket Visualizzatore (roles/storage.bucketViewer).
    • Nel account di servizio ate-snapshot-transfer, concedi al account di servizio Kubernetes ate-api-server il ruolo Creatore token service account (roles/iam.serviceAccountTokenCreator). Il account di servizio ate-api-server simula l'identità del account di servizio ate-snapshot-transfer per emettere le credenziali per ogni attore.
    • Se utilizzi il runtime microVM, concedi al service account Kubernetes atelet il ruolo Storage Object Viewer (roles/storage.objectViewer) sul bucket degli asset.

    Per l'elenco completo delle associazioni e dei comandi gcloud equivalenti, consulta Cosa concede effettivamente create iam nel file README di setup-gcp.

  • Famiglie di VM:

    • Architetture di CPU miste: Agent Substrate su GKE non supporta le serie di macchine per uso generico eseguite su architetture della CPU miste (come i tipi di macchine E2) a causa di un problema noto in gVisor.
    • Tipi di VM uniformi per template di attore: tutti gli attori che crei da un ActorTemplate devono essere eseguiti sullo stesso tipo di VM. Un ActorTemplate non è una risorsa Kubernetes e non ha un selettore di nodi. Invece, il campo workerSelector di ActorTemplate seleziona le risorse WorkerPool in base alle loro etichette. Ogni WorkerPool può selezionare i nodi per i propri worker utilizzando il campo spec.template.nodeSelector. Ad esempio, se il tuo cluster ha pool di nodi che utilizzano VM C4 e VM N2, configura ogni WorkerPool in modo che selezioni i nodi di un solo tipo di VM. Quindi, imposta il campo workerSelector di ActorTemplate in modo che corrisponda solo alle risorse WorkerPool che utilizzano VM C4.
    • Virtualizzazione nidificata o bare metal per i runtime di microVM: il runtime di microVM esegue ogni sandbox nella propria macchina virtuale, quindi i worker che utilizzano questo runtime hanno bisogno di nodi che possano eseguire macchine virtuali. Questi nodi devono utilizzare l'architettura della CPU x86, non Arm. Quando il programma di installazione crea un cluster, il pool di nodi che crea ha la virtualizzazione nidificata abilitata. Se installi Agent Substrate su GKE in un cluster esistente o aggiungi i tuoi pool di nodi per i worker microVM, utilizza un pool di nodi con la virtualizzazione nidificata abilitata o che utilizza un tipo di macchina x86 bare metal. Puoi attivare la virtualizzazione nidificata solo quando crei un pool di nodi. Per verificare quali serie di macchine supportano la virtualizzazione nidificata, ad esempio C3, C4, N2 e N4, consulta Confronto tra serie di macchine.

  • Supporto delle GPU: il passthrough dei dispositivi GPU nei container Actor non è supportato. Se specifichi nvidia.com/gpu, i pod vengono posizionati solo su nodi abilitati per GPU, ma il dispositivo GPU non viene passato al container Actor. Inoltre, gVisor non può acquisire snapshot di contesti CUDA attivi.

  • Connessioni di rete aperte: le connessioni di rete aperte (come le sessioni di database o le connessioni ai server MCP) non vengono conservate quando un agente viene sospeso. Il codice dell'agente deve gestire la riconnessione ai servizi esterni quando l'agente riprende.

  • Osservabilità e OpenTelemetry gestito: OpenTelemetry gestito per GKE presenta le seguenti limitazioni:

    • I connettori di raccolta non sono supportati, il che richiede l'utilizzo di un misuratore proxy esterno per il benchmarking della telemetria.
    • I deployment del Collector comportano un overhead della memoria cache che scala in modo lineare con il numero di pod nei cluster di grandi dimensioni.
    • TLS non è supportato in OpenTelemetry gestito per GKE.

  • Archiviazione: Agent Substrate su GKE utilizza i seguenti bucket Cloud Storage, che vengono creati dal programma di installazione se non esistono:

    • Bucket di snapshot: archivia gli snapshot di tutti gli agenti nel tuo cluster. Questo bucket è obbligatorio.
    • Bucket di asset: archivia i file necessari al runtime della microVM, come un kernel Linux e un file system radice. Il runtime microVM utilizza questi file per eseguire ogni sandbox nella propria macchina virtuale. Il nome di questo bucket è il nome del bucket di snapshot seguito da -assets. Ad esempio, se il bucket di snapshot è denominato example-snapshots, il bucket di asset è denominato example-snapshots-assets. Se non utilizzi il runtime microVM, questo bucket rimane vuoto.

  • Impostazioni del kernel per un'elevata densità di sandbox: l'esecuzione di più di circa 800 sandbox simultanee su un nodo supera i limiti predefiniti nel kernel Linux per il monitoraggio del file system (inotify) e per la tabella adiacente del protocollo di risoluzione degli indirizzi (ARP). Senza limiti più elevati, le sandbox potrebbero non avviarsi e il networking potrebbe bloccarsi. Il programma di installazione applica le impostazioni del kernel richieste ai cluster che crea. Se installi Agent Substrate su GKE in un cluster esistente o aggiungi i tuoi pool di nodi, devi applicare queste impostazioni manualmente. Per i valori richiesti, consulta Requisiti del cluster e Progetta l'infrastruttura per Agent Substrate su GKE.

  • Ambiente di installazione: non puoi installare Agent Substrate su GKE in Cloud Shell. Cloud Shell ha un limite di spazio di archiviazione su disco permanente di 5 GB, che non fornisce spazio su disco sufficiente per l'installazione. Devi installare Agent Substrate su GKE da una workstation locale o da una macchina virtuale (VM) con spazio su disco sufficiente.

Passaggi successivi