Agent Substrate in GKE

Agent Substrate on GKE führt agentische Arbeitslasten im großen Maßstab in Kubernetes-Clustern aus. Es behebt ein häufiges Problem mit der Ressourceneffizienz: Interaktive Agenten (wie persönliche Assistenten und Programmieragenten) verbringen oft die meiste Zeit damit, auf Nutzereingaben oder externe Trigger zu warten. Wenn diese inaktiven Agents kontinuierlich ausgeführt werden, werden CPU und Arbeitsspeicher belegt, die sonst aktiven Arbeitslasten zugewiesen werden könnten.

Agent Substrate in GKE löst dieses Problem, indem inaktive Agents angehalten und ein Snapshot des aktiven Arbeitsspeichers (RAM) und der lokalen Dateien des Agents erstellt wird. Wenn der gesperrte Agent wieder aktiv werden muss, stellt das System den Status des Agents in weniger als einer Sekunde in einer verfügbaren Sandbox wieder her.

Agent Substrate in der GKE baut auf den Funktionen von Agent Sandbox in der GKE auf und verbessert Agent Sandbox in der GKE, indem die Engpässe der Standard-Kubernetes-Steuerungsebene umgangen werden. Dadurch werden deutlich mehr gleichzeitige Agents pro Maschine ausgeführt und die Startzeiten der Agents drastisch reduziert.

Bei Standard-Kubernetes-Bereitstellungen (einschließlich Agent Sandbox in GKE) wird jede Agent-Arbeitslast einem dedizierten Pod zugeordnet. Kubernetes ist zwar hochskalierbar, wird aber durch den Planungsdurchsatz und die Startlatenz von Pods eingeschränkt. Außerdem unterstützt Kubernetes keine Pods im Ruhezustand. Wenn Millionen inaktiver Agents in einem Cluster verbleiben, werden die Pod-Limits und der Arbeitsspeicher der Steuerungsebene erschöpft. Um nicht für inaktive Rechenleistung zu bezahlen, müssen Sie die Pods herunterfahren und den Agent-Status in einem externen Speicher verwalten. Agent Substrate in der GKE löst diese Skalierungseinschränkungen, indem der Agent-Status von den zugrunde liegenden Pods entkoppelt wird: Millionen von ausgesetzten Agent-Snapshots werden im Speicher gespeichert und bei Bedarf in einem freigegebenen Pool von warmen Workern wiederhergestellt.

Agent Substrate in der GKE ist ein Open-Source-System, das Sie direkt in Ihren eigenen GKE Standard-Clustern bereitstellen. Das Kernprojekt wird im Open-Source-Agent Substrate-Repository entwickelt. Google stellt jedoch im substrate-gke-Repository für berechtigte Google Cloud -Kunden GKE-optimierte Bereitstellungstools und ‑Skripts bereit.

Vorteile von Agent Substrate in GKE

Mit Agent Substrate in GKE können Sie die folgenden Ziele erreichen:

  • Nicht vertrauenswürdigen Code sicher ausführen: Agent Substrate in der GKE erzwingt die Kernel- und Netzwerkisolation, sodass Sie KI-generierten Code ausführen können, ohne Ihre gesamte Infrastruktur zu gefährden.
  • Langfristig ausgelegte, zustandsorientierte KI-Agenten erstellen: Der Arbeitsspeicher und die Dateien eines KI-Agenten bleiben über Sitzungen hinweg erhalten. Der KI-Agent setzt die Arbeit genau an der Stelle fort, an der er pausiert wurde.
  • In Echtzeit auf Anfragen reagieren: Wenn eine neue Anfrage einen angehaltenen Agenten auslöst, stellt das System den Status des Agenten in Sekundenbruchteilen wieder her.
  • Computing-Kosten senken: Sie können mehr Agenten auf weniger Maschinen ausführen, indem Sie einen Pool von Worker-Sandboxes für alle Ihre Agenten freigeben. Da inaktive Agenten gesperrt sind und keine CPU und keinen Arbeitsspeicher verwenden, zahlen Sie nur für die Rechenleistung, wenn Agenten aktiv Aufgaben verarbeiten.

Anwendungsfälle

Agent Substrate in der GKE ist für die Ausführung von Agenten in jeder Größenordnung konzipiert, von Dutzenden bis zu Millionen gleichzeitiger Agenten. Hier sind drei Beispielarbeitslasten:

  • Produktivitäts-KI-Agenten: Langfristige Hintergrundassistenten, die den Kontext über Wochen hinweg beibehalten. Da diese Assistenten die meiste Zeit auf Trigger warten, werden die Rechenkosten gesenkt, wenn die Arbeitslasten bei Nichtgebrauch gesperrt werden.
  • Sitzungsbasierte Sandboxes: Isolierte On-Demand-Umgebungen zum Ausführen von nicht vertrauenswürdigem, von LLMs generiertem Code, zum Ausführen von Toolaufrufen oder zum Analysieren von Daten. Da Sandboxes in weniger als einer Sekunde wiederhergestellt werden, kann das System Einwegumgebungen für kurzlebige Aufgaben bereitstellen und Ressourcen freigeben, wenn die Ausführung abgeschlossen ist.
  • Coding-Agenten: KI-Assistenten, die in Echtzeit mit Entwicklern kommunizieren, um Code zu schreiben, zu erstellen und zu testen. Der KI-Agent führt Terminalbefehle aus und ändert Dateien in einer Sandbox. Wenn der Agent inaktiv ist, wird er vom System angehalten, bis der Entwickler einen weiteren Prompt sendet.

Funktionsweise von Agent Substrate in der GKE

Agent Substrate in der GKE basiert auf Kubernetes, aber Sie müssen Kubernetes nicht verstehen, um es zu verwenden. Die wichtigsten Konzepte von Agent Substrate in GKE sind:

  • Akteur: eine einzelne laufende Instanz eines KI-Agenten.
  • ActorTemplate: Eine Konfigurationsvorlage (mit Container-Images, Umgebungsvariablen und Rechenressourcen), die zum Instanziieren von Akteuren verwendet wird.
  • Worker: Eine sichere Sandbox, in der ein aktiver Actor ausgeführt wird.
  • WorkerPool: Eine Gruppe von vorab gestarteten, inaktiven Workern, die bereitgehalten werden, um einen Actor zu empfangen.

Da ein Actor nicht an einen bestimmten Worker gebunden ist, kann das System inaktive Agents sperren und die freigegebene Rechenleistung wiederverwenden. Mit dieser Architektur kann das System Millionen von Agenten auf einer begrenzten Anzahl von Maschinen ausführen.

Ein typischer Agentenlebenszyklus umfasst die folgenden Schritte:

  1. Routing: Jede eingehende API-Anfrage von Ihrer Anwendung gibt den Ziel-Actor an. Wenn ein Nutzer beispielsweise einen neuen Prompt in eine Chatoberfläche eingibt, sendet Ihre Anwendung eine Anfrage an den spezifischen Actor, der die Sitzung des Nutzers verwaltet.
  2. Fortsetzen: Wenn die Anfrage für einen gesperrten Actor gilt, fordert das System einen warmen Worker aus dem WorkerPool an und stellt den Snapshot des Actors auf diesem Worker wieder her.
  3. Wird ausgeführt: Das System leitet die Anfrage an diesen neu aktivierten Worker weiter und der Actor verarbeitet die Aufgabe.
  4. Anhalten: Wenn der Actor seine Arbeit beendet hat und inaktiv wird, erstellt das System einen neuen Snapshot des Arbeitsspeichers und der Dateien des Actors, speichert den Snapshot im Speicher und gibt den leeren Worker wieder an den Pool frei.

Arbeitslastisolierung und GKE Sandbox

Agent Substrate in GKE verwendet gVisor oder Cloud Hypervisor, um jede Arbeitslast in einer Sandbox auszuführen, die den Anwendungscode vom Host-Kernel isoliert. Die Installation von Agent Substrate in der GKE umfasst eine gVisor-Laufzeit für Worker, sodass Sie die GKE Sandbox auf den zugrunde liegenden GKE-Knoten nicht konfigurieren müssen.

Beschränkungen und Anforderungen

Für Agent Substrate in GKE gelten die folgenden Einschränkungen und Anforderungen:

  • Clusterversion und Beta-APIs: Agent Substrate in GKE wird auf GKE Standard-Clustern mit Version 1.36 (mit aktivierten Beta-Flags) oder Version 1.37 oder höher unterstützt. Versionen vor 1.36 werden nicht unterstützt. Außerdem sind für GKE die Beta-APIs (podcertificaterequests und clustertrustbundles) erforderlich. Wenn Sie diese APIs in einem vorhandenen Cluster mit Version 1.36 aktivieren, müssen Sie auch die vorhandenen Knoten ersetzen, damit die Pod-Zertifikatsprojektion auf ihnen aktiviert wird. In Version 1.37 oder höher müssen vorhandene Knoten nicht ersetzt werden.
  • Workload Identity Federation for GKE: Für GKE-Cluster muss die Workload Identity Federation for GKE aktiviert sein. Agent Substrate in GKE verwendet Workload Identity Federation for GKE, um sich bei Google Cloud -APIs wie Cloud Storage zu authentifizieren, um Agent-Snapshots zu speichern.
  • VM-Familien:
    • Gemischte CPU-Architekturen: Agent Substrate in GKE unterstützt keine Maschinenserien für allgemeine Zwecke, die auf gemischten CPU-Architekturen ausgeführt werden (z. B. E2-Maschinentypen), da ein bekanntes Problem mit gVisor vorliegt.
    • Einheitliche VM-Typen pro Actor-Vorlage: Das Mischen von VM-Typen innerhalb einer einzelnen ActorTemplate (der Konfigurations-Blueprint, der zum Erstellen von Actors verwendet wird) wird nicht unterstützt. Wenn Ihr Cluster beispielsweise zwei Knotenpools mit C4- und N2-VMs hat, muss ein ActorTemplate einen Knotenselektor enthalten, der einen einzelnen VM-Typ (z. B. C4) angibt, um zu verhindern, dass Akteure für diese Vorlage auf verschiedene Maschinentypen aufgeteilt werden.
  • GPU-Unterstützung: Die GPU-Geräteweiterleitung an Actor-Container wird nicht unterstützt. Wenn Sie nvidia.com/gpu angeben, werden Pods nur auf GPU-fähigen Knoten platziert, das GPU-Gerät wird jedoch nicht an den Actor-Container übergeben. Außerdem kann gVisor keine Snapshots von Live-CUDA-Kontexten erstellen.
  • Netzwerk:
    • Richtlinien für ausgehenden Traffic: EgressPolicy-Regeln (Netzwerksteuerung nach Hostname und IP-Adresse) werden nicht unterstützt, einschließlich der folgenden Funktionen:
      • Standard-Ablehnungsregeln
      • Hostnamebasierte Regeln
      • Credential Injection
    • Offene Verbindungen: Offene Netzwerkverbindungen (z. B. Datenbanksitzungen oder Verbindungen zu MCP-Servern) werden nicht beibehalten, wenn ein Agent angehalten wird. Ihr Agentencode muss die Wiederherstellung der Verbindung zu externen Diensten verarbeiten, wenn der Agent fortgesetzt wird.
  • Beobachtbarkeit und verwaltetes OpenTelemetry: Für verwaltetes OpenTelemetry für GKE gelten die folgenden Einschränkungen:
    • Collector-Connectors werden nicht unterstützt. Daher muss ein externer Proxy-Meter für das Telemetrie-Benchmarking verwendet werden.
    • Collector-Bereitstellungen verursachen einen Speicher-Cache-Overhead, der in großen Clustern linear mit der Anzahl der Pods skaliert.
    • TLS wird in Managed OpenTelemetry for GKE nicht unterstützt.
  • Speicher: Das System benötigt Cloud Storage, um die Snapshots Ihrer Agenten zu speichern.
  • Installationsumgebung: Sie können Agent Substrate nicht in der GKE in Cloud Shell installieren. Cloud Shell hat ein Limit von 5 GB für nichtflüchtigen Speicher, was nicht genügend Speicherplatz für die Installation bietet. Sie müssen Agent Substrate auf GKE von einer lokalen Workstation oder einer virtuellen Maschine (VM) mit ausreichend Speicherplatz installieren.

Nächste Schritte