Agent-Sandbox in GKE

Mit der Agent Sandbox in der Google Kubernetes Engine (GKE) können Sie isolierte, zustandsorientierte Arbeitslasten mit einem einzelnen Replikat verwalten, indem Sie jede Sandbox in einem dedizierten Kubernetes-Pod ausführen. Diese Pod-basierte Architektur unterstützt Anwendungsfälle wie KI-Agent-Laufzeiten, bei denen nicht vertrauenswürdiger, von LLM generierter Code in einer isolierten Umgebung ausgeführt werden muss.

Agent Sandbox ist ein Open-Source-Projekt unter Kubernetes SIG Apps. Wenn Sie die Agent Sandbox in GKE verwenden möchten, müssen Sie den Agent Sandbox-Controller in Ihrem Cluster installieren. Sie sind für das Upgrade des Controllers verantwortlich. Eine Anleitung finden Sie unter Agent Sandbox in der GKE installieren.

Dieses Dokument bietet eine konzeptionelle Übersicht über die Agent Sandbox in GKE.

Zwischen Pod-basierten und Akteur-basierten Architekturen wählen

Die GKE bietet zwei Architekturen für die Orchestrierung von KI-Agenten-Arbeitslasten:

  • Agent Substrate in der GKE (akteur-basiert): Verwenden Sie diese Architektur für die meisten agentischen Arbeitslasten, insbesondere für zustandsorientierte Agenten, die häufig angehalten und fortgesetzt werden. Aktive Agenten teilen sich einen Pool von warmen Pods, anstatt einen dedizierten Pod pro Agent zu haben. So können Sie mehr Agenten auf weniger Knoten ausführen. Agent Substrate in GKE bietet automatisches Pausieren und Fortsetzen für inaktive Arbeitslasten. Das System speichert den Arbeitsspeicher und die Dateien jedes inaktiven KI-Agenten im Speicher und stellt den KI-Agenten in weniger als einer Sekunde wieder her. Im Gegensatz dazu erfordert die Agent Sandbox in GKE manuelle Pod-Snapshots. Außerdem müssen Sie Anwendungscode erstellen, um Inaktivität zu erkennen und den Fortschritt des KI-Agenten zu speichern. Agent Substrate in GKE erfordert einen GKE-Standardcluster. Weitere Informationen finden Sie unter Agent Substrate in der GKE.
  • Agent Sandbox in der GKE (Pod-basiert): Verwenden Sie diese Architektur, wenn jeder Agent einen dedizierten Kubernetes-Pod in einem GKE Autopilot- oder Standard-Cluster benötigt. Wählen Sie diese Option für kontinuierlich aktive Agents oder Arbeitslasten aus, die eine der folgenden Anforderungen haben:
    • Deklarative Kubernetes APIs, z. B. die benutzerdefinierten Ressourcen Sandbox und SandboxClaim
    • Das vollständige Kubernetes-PodSpec-Schema, einschließlich benutzerdefinierter Sidecar- und Init-Container
    • Direkter Zugriff auf Hardwarebeschleuniger wie GPUs oder TPUs
    • GKE Autopilot-Cluster

Vorteile der Agent Sandbox in der GKE

Die Agent Sandbox in GKE ist für agentische Arbeitslasten konzipiert, die ein hohes Maß an Skalierbarkeit, Erweiterbarkeit und Sicherheit erfordern. Zu den wichtigsten Vorteilen gehören:

  • Isolation auf Kernelebene: Bietet eine starke Isolation auf Kernelebene für nicht vertrauenswürdigen, von LLM generierten Code. Agent Sandbox in GKE funktioniert auch mit Open-Source-Kata-Containern. Eine Anleitung zur Verwendung von Open-Source-Kata-Containern mit Agent Sandbox in der GKE finden Sie unter Kata-Container in der GKE aktivieren.

  • Bereitstellung in weniger als einer Sekunde: Sandboxes werden aus einem Warmpool bereitgestellt, in der Regel in weniger als einer Sekunde, anstatt auf die standardmäßige Kubernetes-Pod-Planung und den Start zu warten.

  • Cloudnative Erweiterbarkeit: Nutzt die Leistungsfähigkeit des Kubernetes-Paradigmas und die verwaltete Infrastruktur von GKE.

Durch die Bereitstellung einer deklarativen, standardisierten API bietet Agent Sandbox in GKE eine Single-Container-Umgebung mit Isolations- und Persistenzmerkmalen, die einer virtuellen Maschine (VM) ähneln und vollständig auf Kubernetes-Primitiven basieren.

Häufige Anwendungsfälle für Agent Sandbox in GKE

Verwenden Sie Agent Sandbox in GKE für Arbeitslasten, die Isolation, Persistenz und eine stabile Identität erfordern. Beispiel-Anwendungsfälle umfassen Folgendes:

  • KI-Agent-Laufzeiten: Nicht vertrauenswürdigen Code sicher in einer Umgebung ausführen, die durch sicherheitsorientierte Laufzeiten wie gVisor isoliert ist.
  • Entwicklungsumgebungen: Stellen Sie Entwicklern persistente, isolierte, cloudbasierte Programmierumgebungen zur Verfügung.
  • Notebooks und Recherchetools: Hostet Single-Container-Sitzungen für interaktive Tools wie Jupyter Notebooks.
  • Zustandsorientierte Dienste mit einem einzelnen Pod: Führen Sie Anwendungen aus, die eine stabile Identität und einen stabilen Speicher benötigen, ohne die Komplexität eines StatefulSet.
  • Programmatische Umgebungsverwaltung: Verwenden Sie die bereitgestellten Clientbibliothek-SDKs, z. B. das Agent Sandbox Python SDK, um Sandboxes direkt über Ihre Anwendungslogik anzufordern und zu verwalten, ohne Kubernetes-YAML verwalten zu müssen.

Funktionsweise der Agent Sandbox in der GKE

Die Agent Sandbox in der GKE verwendet einen benutzerdefinierten Controller und mehrere benutzerdefinierte Kubernetes-Ressourcendefinitionen (CRDs), um den Lebenszyklus von Sandbox-Umgebungen zu verwalten.

Kernarchitektur

  • Benutzerdefinierte Sandbox-Ressource: Die primäre Ressource, die einen einzelnen zustandsorientierten Pod darstellt. Die Ressource verwaltet stabile Hostnamen, Netzwerkidentitäten und nichtflüchtigen Speicher.
  • Sandbox-Router: Eine Komponente, die einen stabilen Endpunkt bereitstellt und Traffic an die entsprechenden Sandbox-Pods tunnelt, wodurch die zugrunde liegende Netzwerkkomplexität abstrahiert wird.
  • Integration in Pod-Snapshots: Die Agent Sandbox in GKE ist in die Funktion GKE-Pod-Snapshots eingebunden, sodass Arbeitslasten pausiert und fortgesetzt werden können, indem der vollständige Status eines Containers gespeichert und wiederhergestellt wird.

Modell beanspruchen

Das Anspruchsmodell ist ein wichtiges Feature, das die Anfrage des Nutzers nach einer Umgebung von den spezifischen Implementierungsdetails trennt, z. B. wo und wie die Arbeitslast bereitgestellt wird. Im Gegensatz zu einem Standard-Kubernetes-StatefulSet können Sie mit dem Anforderungsmodell eine Sandbox anfordern, ohne die zugrunde liegenden Pod- oder Speicherkonfigurationen direkt verwalten zu müssen.

Das Anspruchsmodell verwendet die benutzerdefinierten Ressourcen SandboxClaim, SandboxWarmPool und SandboxTemplate und funktioniert so:

  1. Nutzer oder Anwendungen fordern eine Sandbox an, indem sie eine SandboxClaim-Ressource erstellen, die auf eine SandboxWarmPool-Ressource verweist. Der Warmpool verweist auf die Ressource SandboxTemplate, die die Sandbox-Konfiguration definiert.
  2. Der Controller weist dem Anspruch eine bereite Sandbox aus dem Warmpool zu. Wenn keine Sandbox im Pool bereit ist, erstellt der Controller eine neue Sandbox für die Anforderung aus der Vorlage.

Warme Pools

Das Feature Warm Pool wurde entwickelt, um die Startlatenz für interaktive KI-Agenten-Szenarien zu minimieren. Durch die Verwendung eines Warm Pools kann die Agent Sandbox in GKE Ausführungsumgebungen in weniger als einer Sekunde bereitstellen. Das Feature verwendet die benutzerdefinierte Ressource SandboxWarmPool und funktioniert so:

  1. Eine SandboxWarmPool-Ressource verwaltet eine Reihe von vorbereiteten Pod-Instanzen in einem bereiten Zustand.
  2. Wenn eine SandboxClaim-Ressource erstellt wird, weist der Controller einen bereiten Pod aus dem Pool zu, anstatt darauf zu warten, dass ein neuer Pod Images abruft und von Grund auf neu startet.
  3. In Kombination mit Pod-Snapshots können warme Pools Pods aus einem vorkonfigurierten Zustand wiederherstellen, anstatt sie von Grund auf neu zu starten.

Netzwerkisolation

Die Agent Sandbox in GKE implementiert einen Netzwerksicherheitsstatus vom Typ Standardmäßig ablehnen für Sandboxes, die Sie aus einer SandboxTemplate-Ressource erstellen. Für jede SandboxTemplate-Ressource erstellt der Controller eine NetworkPolicy-Ressource, die dafür sorgt, dass nicht vertrauenswürdiger Code, der in einer Sandbox ausgeführt wird, standardmäßig nicht auf nicht autorisierte interne Netzwerke oder die GKE-Steuerungsebene zugreifen kann. Sie können in Ihrer SandboxTemplate-Ressource bestimmte Netzwerkeinschränkungen und zulässige Regeln für ausgehenden oder eingehenden Traffic definieren, um eine detaillierte Sicherheit für agentische Arbeitslasten zu gewährleisten.

Der Controller erstellt keine NetworkPolicy-Ressource für eine Sandbox-Ressource, die Sie direkt erstellen. Wenn Sie den Netzwerkzugriff für diese Sandboxes einschränken möchten, erstellen Sie eine eigene NetworkPolicy-Ressource.

Programmatischer Zugriff mit SDKs

KI-Entwickler können die Agent Sandbox für GKE-Ressourcen programmatisch über die bereitgestellten Clientbibliotheken nutzen. Das Python SDK bietet beispielsweise eine allgemeine Schnittstelle, die die zugrunde liegende SandboxClaim-Ressource für Sie erstellt. Der Anspruch verweist auf eine von Ihnen erstellte SandboxWarmPool-Ressource. Über diese Schnittstelle können Sie isolierte Umgebungen direkt aus Ihren Python-basierten KI-Agenten-Frameworks wie LangChain oder dem Vertex AI Agentic SDK erstellen und mit ihnen interagieren.

Beschränkungen und Anforderungen

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

  • Clusterversion: Agent Sandbox in GKE kann auf jeder unterstützten GKE-Version ausgeführt werden. Wenn Sie Pod-Snapshots verwenden möchten, muss auf Ihrem Cluster die GKE-Version 1.35.3-gke.1234000 oder höher ausgeführt werden.
  • Infrastrukturanforderungen: Der Agent Sandbox-Controller muss im Cluster installiert und konfiguriert sein. Für die Agent Sandbox in GKE ist kein bestimmter Maschinentyp erforderlich. In der Installationsanleitung werden beispielsweise e2-standard-2-Knoten verwendet. Pod-Snapshots unterstützen jedoch keine E2-Maschinentypen. Wenn Sie Pod-Snapshots verwenden möchten, sollten Sie eine andere Maschinenserie wie N2 verwenden.
  • Isolationslaufzeiten: Die Agent Sandbox in GKE unterstützt gVisor und microVMs als Isolationslaufzeiten. Pod-Snapshots erfordern gVisor und funktionieren nicht mit MicroVMs. Wenn Sie keine Sandbox-Laufzeit angeben, werden Sandboxen ohne Kernel-Isolierung ausgeführt. Dies wird für nicht vertrauenswürdigen Code nicht empfohlen.
  • Verfügbarkeit zugrunde liegender Funktionen: Einige zugrunde liegende Funktionen, z. B. GKE-Pod-Snapshots, sind möglicherweise in der Vorabversion oder nur in bestimmten Regionen verfügbar.

Nächste Schritte