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 verbraucht, die sonst aktiven Arbeitslasten zugewiesen werden könnten.

Agent Substrate in der GKE löst dieses Problem, indem Ihre Anwendung inaktive Agents sperren kann. Wenn Ihre Anwendung einen Agenten anhält, erstellt das System einen Snapshot des aktiven Arbeitsspeichers (RAM) und der lokalen Dateien des Agenten. Wenn der ausgesetzte 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. Daher werden mit Agent Substrate in der GKE mehr gleichzeitige Agenten pro Maschine ausgeführt und Agenten schneller gestartet als mit Agent Sandbox in der GKE. Informationen zum Vergleichen von Agent Substrate in der GKE mit Agent Sandbox in der GKE und zum Auswählen einer Architektur für Ihre KI-Agent-Arbeitslasten finden Sie unter Architektur für KI-Agent-Arbeitslasten in der GKE planen.

Bei Standard-Kubernetes-Bereitstellungen (einschließlich Agent Sandbox in GKE) wird jede Agent-Arbeitslast einem dedizierten Pod zugeordnet. Kubernetes ist zwar hochgradig skalierbar, 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 der GKE

Mit Agent Substrate in der GKE können Sie Folgendes 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 Zustand 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: On-Demand-isolierte Umgebungen zum Ausführen von nicht vertrauenswürdigem, von LLM 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 KI-Agent inaktiv ist, wird er von Ihrer Anwendung 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 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 die Computing-Ressourcen wiederverwenden, die ein Actor freigibt, wenn Ihre Anwendung ihn anhält. Dank 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. Ausführen: Das System leitet die Anfrage an diesen neu aktivierten Worker weiter und der Actor verarbeitet die Aufgabe.
  4. Sperren: Wenn Ihre Anwendung einen inaktiven Actor sperrt, 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.

Arbeitslastisolation 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 eigene gVisor-Laufzeit für Worker. Aktivieren Sie GKE Sandbox nicht in den Knotenpools, in denen Agent Substrate on GKE ausgeführt wird, da Agent Substrate on GKE auf diesen Knoten nicht ausgeführt werden kann. Sie können GKE Sandbox weiterhin für andere Arbeitslasten verwenden, einschließlich Agent Sandbox in GKE.

Beschränkungen und Anforderungen

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

  • Clustermodus, Version und Release-Version: Agent Substrate in der GKE unterstützt GKE Standard-Cluster, deren Steuerungsebene und Knotenpools Version 1.37 oder höher ausführen. Autopilot-Cluster und Versionen vor 1.37 werden nicht unterstützt. In Version 1.37 und höher stellt GKE die Kubernetes APIs podcertificaterequests und clustertrustbundles bereit und ermöglicht es Knoten, Pod-Zertifikate und Trust Bundles in Pods einzubinden. Sie müssen die Betaversionen dieser APIs also nicht selbst aktivieren. Das Installationsprogramm aktiviert jedoch die Betaversionen in jedem Cluster, den es erstellt oder konfiguriert. Da die Release-Version „Erweitert“ keine explizit aktivierten Beta-APIs unterstützt, können Sie das Installationsprogramm nicht mit Clustern verwenden, die für die Release-Version „Erweitert“ registriert sind.

  • 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. Zum Speichern und Wiederherstellen von Snapshots verwendet das System ein dediziertes Dienstkonto mit dem Namen ate-snapshot-transfer. Mit den Anmeldedaten für jeden Speicher- oder Wiederherstellungsvorgang kann nur auf die Snapshots eines Akteurs zugegriffen werden. Daher müssen Sie Ihren GKE-Knoten keinen Zugriff auf den Snapshot-Bucket gewähren. Das Installationsprogramm erstellt das Dienstkonto ate-snapshot-transfer und gewährt ihm Zugriff auf den Snapshot-Bucket. Wenn Sie die Berechtigungen selbst einrichten, weisen Sie die folgenden IAM-Rollen zu:

    • Weisen Sie dem Dienstkonto ate-snapshot-transfer und dem Kubernetes-Dienstkonto ate-api-server für den Snapshot-Bucket die Rollen „Storage-Objekt-Administrator“ (roles/storage.objectAdmin) und „Storage-Bucket-Betrachter“ (roles/storage.bucketViewer) zu.
    • Weisen Sie dem Kubernetes-Dienstkonto ate-api-server für das Dienstkonto ate-snapshot-transfer die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) zu. Das Dienstkonto ate-api-server übernimmt die Identität des Dienstkontos ate-snapshot-transfer, um die Anmeldedaten für jeden Akteur auszustellen.
    • Wenn Sie die microVM-Laufzeit verwenden, weisen Sie dem Kubernetes-Dienstkonto atelet die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) für den Asset-Bucket zu.

    Eine vollständige Liste der Bindungen und der entsprechenden gcloud-Befehle finden Sie in der README-Datei zu setup-gcp unter What create iam actually grants.

  • 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 in gVisor vorliegt.
    • Einheitliche VM-Typen pro Actor-Vorlage: Alle Actors, die Sie aus einer ActorTemplate erstellen, müssen auf demselben VM-Typ ausgeführt werden. Ein ActorTemplate ist keine Kubernetes-Ressource und hat keinen Knotenselektor. Stattdessen werden im Feld workerSelector des ActorTemplate die WorkerPool-Ressourcen anhand ihrer Labels ausgewählt. Jeder WorkerPool kann die Knoten für seine Worker über das Feld spec.template.nodeSelector auswählen. Wenn Ihr Cluster beispielsweise Knotenpools mit C4- und N2-VMs hat, konfigurieren Sie jede WorkerPool so, dass nur Knoten eines VM-Typs ausgewählt werden. Legen Sie dann das Feld workerSelector der ActorTemplate so fest, dass es nur mit den WorkerPool-Ressourcen übereinstimmt, die C4-VMs verwenden.
    • Verschachtelte Virtualisierung oder Bare Metal für MicroVM-Laufzeiten: Die MicroVM-Laufzeit führt jede Sandbox in einer eigenen virtuellen Maschine aus. Worker, die diese Laufzeit verwenden, benötigen daher Knoten, auf denen virtuelle Maschinen ausgeführt werden können. Diese Knoten müssen die x86-CPU-Architektur verwenden, nicht Arm. Wenn das Installationsprogramm einen Cluster erstellt, ist für den erstellten Knotenpool die verschachtelte Virtualisierung aktiviert. Wenn Sie Agent Substrate in GKE in einem vorhandenen Cluster installieren oder eigene Knotenpools für MicroVM-Worker hinzufügen, verwenden Sie einen Knotenpool, für den die verschachtelte Virtualisierung aktiviert ist oder der einen x86-Bare-Metal-Maschinentyp verwendet. Sie können die verschachtelte Virtualisierung nur aktivieren, wenn Sie einen Knotenpool erstellen. Informationen dazu, welche Maschinenserien die verschachtelte Virtualisierung unterstützen, z. B. C3, C4, N2 und N4, finden Sie im Vergleich der Maschinenserien.

  • GPU-Unterstützung: Die Weiterleitung von GPU-Geräten 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.

  • Offene Netzwerkverbindungen: 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: Verwaltetes OpenTelemetry für GKE hat 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: Agent Substrate in GKE verwendet die folgenden Cloud Storage-Buckets, die vom Installationsprogramm erstellt werden, wenn sie nicht vorhanden sind:

    • Snapshot-Bucket: Speichert die Snapshots aller Agents in Ihrem Cluster. Dieser Bucket ist erforderlich.
    • Asset-Bucket: Speichert die Dateien, die die MicroVM-Laufzeit benötigt, z. B. einen Linux-Kernel und ein Root-Dateisystem. Die microVM-Laufzeit verwendet diese Dateien, um jede Sandbox in einer eigenen virtuellen Maschine auszuführen. Der Name dieses Buckets ist der Name des Snapshot-Buckets, gefolgt von -assets. Wenn Ihr Snapshot-Bucket beispielsweise example-snapshots heißt, lautet der Name des Asset-Buckets example-snapshots-assets. Wenn Sie die MicroVM-Laufzeit nicht verwenden, bleibt dieser Bucket leer.

  • Kernel-Einstellungen für hohe Sandbox-Dichte: Wenn mehr als etwa 800 gleichzeitige Sandboxes auf einem Knoten ausgeführt werden, werden die Standardlimits im Linux-Kernel für das Dateisystem-Monitoring (inotify) und für die Nachbartabelle des Address Resolution Protocol (ARP) überschritten. Ohne höhere Limits können Sandboxes möglicherweise nicht gestartet werden und das Netzwerk kann ins Stocken geraten. Das Installationsprogramm wendet die erforderlichen Kernel-Einstellungen auf die von ihm erstellten Cluster an. Wenn Sie Agent Substrate in GKE in einem vorhandenen Cluster installieren oder eigene Knotenpools hinzufügen, müssen Sie diese Einstellungen selbst anwenden. Die erforderlichen Werte finden Sie unter Clusteranforderungen und Infrastruktur für Agent Substrate in GKE entwerfen.

  • 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 in GKE von einer lokalen Workstation oder einer virtuellen Maschine (VM) mit ausreichend Speicherplatz installieren.

Nächste Schritte