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 sospendendo gli agenti inattivi e acquisendo 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 migliora Agent Sandbox su GKE bypassando i colli di bottiglia del control plane Kubernetes standard. Di conseguenza, esegue un numero significativamente maggiore di agenti simultanei per macchina e riduce drasticamente i tempi di avvio degli agenti.

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 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.
  • Riduci i 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 di 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, il sistema 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 sicura in cui viene eseguito un Actor attivo.
  • WorkerPool: un gruppo di worker inattivi pre-avviati che vengono tenuti pronti per ricevere un attore.

Poiché un attore non è legato a un worker specifico, il sistema può sospendere gli agenti inattivi e riutilizzare il computing liberato. 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 rivendica 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'attore termina il suo lavoro e diventa 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 un runtime gVisor per i worker, in modo che non sia necessario configurare GKE Sandbox sui nodi GKE sottostanti.

Limitazioni e requisiti

Agent Substrate su GKE presenta le seguenti limitazioni e requisiti:

  • Versione del cluster e API beta: Agent Substrate su GKE è supportato sui cluster GKE Standard con versione 1.36 (con flag beta abilitati) o versione 1.37 o successive. Le versioni precedenti alla 1.36 non sono supportate. Inoltre, GKE richiede le API beta (podcertificaterequests e clustertrustbundles). Se abiliti queste API su un cluster esistente che esegue la versione 1.36, devi anche sostituire i nodi esistenti in modo che la proiezione dei certificati dei pod sia abilitata su di essi. Nella versione 1.37 o successive, non è necessario sostituire i nodi esistenti.
  • 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.
  • Famiglie di VM:
    • Architetture CPU miste: Agent Substrate su GKE non supporta le serie di macchine per uso generico che vengono eseguite su architetture della CPU miste (come i tipi di macchina E2) a causa di un problema noto con gVisor.
    • Tipi di VM uniformi per template di attore: la combinazione di tipi di VM all'interno di un singolo ActorTemplate (il progetto di configurazione utilizzato per creare gli attori) non è supportata. Ad esempio, se il tuo cluster ha due node pool che utilizzano VM C4 e N2, un ActorTemplate deve includere un selettore di nodi che specifica un singolo tipo di VM (ad esempio C4) per evitare che gli attori per quel template vengano suddivisi tra tipi di macchine diversi.
  • 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.
  • Networking:
    • Policy in uscita: le regole EgressPolicy (controlli di rete per nome host e indirizzo IP) non sono supportate, incluse le seguenti funzionalità:
      • Regole di negazione predefinite
      • Regole basate sul nome host
      • Credential injection
    • Connessioni 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.
  • Spazio di archiviazione: il sistema richiede Cloud Storage per salvare gli snapshot degli agenti.
  • 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