Architektur für KI-Agenten-Arbeitslasten in der GKE planen

Die Google Kubernetes Engine (GKE) bietet zwei Orchestrierungsmodelle für die Ausführung von KI-Agenten in kernelisolierten Sandboxes (mit Cloud Hypervisor-MicroVMs oder gVisor):

  • Agent Substrate in der GKE (akteur-basiert, empfohlen): Verwenden Sie dieses Modell für die meisten KI-Agent-Arbeitslasten, insbesondere für zustandsorientierte, CPU-basierte Agents, die häufig angehalten und fortgesetzt werden. Aktive KI-Agenten-Sitzungen (Akteure) teilen sich einen Pool von Warm-Worker-Pods und können in weniger als einer Sekunde aus Cloud Storage wiederhergestellt werden.
  • Agent Sandbox in GKE (Pod-basiert): Verwenden Sie dieses Modell, wenn jeder Agent einen dedizierten Kubernetes-Pod benötigt. Wählen Sie diese Option für kontinuierlich aktive Agents oder Arbeitslasten aus, die eine vollständige Kubernetes-PodSpec (z. B. Sidecars), GPUs oder TPUs, Arm-Knoten oder GKE Autopilot-Cluster erfordern.

Eine direkte Zusammenfassung der beiden Orchestrierungsmodelle finden Sie unter Agent Substrate und Agent Sandbox vergleichen.

Lesen Sie dieses Dokument, um ein Orchestrierungsmodell, eine Sandbox-Laufzeit, Isolationskontrollen und Speicheroptionen auszuwählen, bevor Sie Ihren GKE-Cluster bereitstellen. Dieses Dokument richtet sich an Lösungsarchitekten, KI-Entwickler sowie Plattformadministratoren und ‑operatoren, die Ausführungsumgebungen für KI-Agenten in der GKE entwerfen.

Architekturanforderungen für KI-Agenten-Arbeitslasten in GKE

Wenn Sie KI-Agenten-Arbeitslasten in der GKE ausführen, können Sie isolierte Agenten-Ausführungsumgebungen im selben Cluster und Netzwerkperimeter wie Ihre unterstützenden Kubernetes-Dienste platzieren und die GKE für die automatische Knotenbereitstellung, Burst-Skalierung und Lebenszyklusverwaltung verwenden.

Im Gegensatz zu kontinuierlich aktiven Mikrodiensten haben KI-Agenten-Arbeitslasten die folgenden architektonischen Anforderungen:

Akteurbasiertes Modell: Agent Substrate in der GKE (empfohlen)

Agent Substrate in GKE ist eine Ausführungslaufzeit, die Agent-Sitzungen (Akteure) von den zugrunde liegenden Kubernetes-Pods entkoppelt. Aktive Akteure teilen sich einen Pool von vorab initialisierten Worker-Pods (WorkerPool-Ressourcen) über Akteurvorlagen (ActorTemplate-Ressourcen) hinweg. Wenn Ihre Anwendung einen inaktiven Akteur sperrt, speichert Agent Substrate den Status des Akteurs in Cloud Storage und gibt seine Worker-Kapazität frei, damit andere Akteure den Knoten verwenden können. Wenn eine neue Anfrage eingeht, stellt Agent Substrate den Akteur in weniger als einer Sekunde auf einem verfügbaren Worker wieder her.

Verwenden Sie Agent Substrate als Standardarchitektur für CPU-basierte Agent-Arbeitslasten, einschließlich der folgenden Anwendungsfälle:

  • Interaktive KI-Agenten für Programmierung: KI-Assistenten, die während Entwicklergesprächen Terminalbefehle ausführen, Code erstellen und Dateien bearbeiten und zwischen Prompts pausieren.
  • Langlebige Produktivitäts-Agents: Hintergrundassistenten, die den Kontext über Tage oder Wochen hinweg beibehalten und die meiste Zeit auf Nutzereingaben oder externe Trigger warten.
  • Kurzlebige Code- und Browser-Sandboxes: On-Demand-Umgebungen zum Ausführen von LLM-generiertem Code, Headless-Browsern oder Toolaufrufen, die in weniger als einer Sekunde wiederhergestellt werden und nach der Ausführung Rechenressourcen freigeben.

Agent Substrate erfordert GKE Standard-Cluster (Version 1.37 oder höher sowohl auf der Steuerungsebene als auch in den Knotenpools) mit x86-CPU-Worker-Knoten. GKE Autopilot wird nicht unterstützt, da der Agent Substrate-Knoten-Agent (atelet) als privilegiertes DaemonSet ausgeführt wird und MicroVM-Worker-Pools verschachtelte Virtualisierung oder Bare-Metal-Knoten erfordern. GPUs und TPUs werden nicht unterstützt.

Identität, Anmeldedaten und ausgehender Netzwerktraffic

Agent Substrate stellt für jeden Akteur ein eindeutiges SPIFFE-X.509-Zertifikat und ein JSON Web Token (JWT) bereit, um Anfragen aus einzelnen Sitzungen zu authentifizieren und zu prüfen. Da mehrere Akteure Worker-Pods im Laufe der Zeit gemeinsam nutzen, sollten Sie die Workload Identity-Föderation für GKE auf Pod-Ebene nur für Worker-Infrastrukturaufgaben verwenden.

Damit API-Schlüssel und Tokens außerhalb der Sandbox bleiben, fügt das integrierte Gateway für ausgehenden Traffic Anmeldedaten in ausgehende Anfragen während der Übertragung ein. Secrets werden in Kubernetes-Secret-Objekten oder in Secret Manager gespeichert. Wenn eine ausgehende HTTP- oder HTTPS-Anfrage mit einer Regel für ausgehenden Traffic übereinstimmt, authentifiziert das Gateway den mTLS-Tunnel des Akteurs und ersetzt Platzhalterheader durch ein abgerufenes Secret oder ein Akteur-JWT. Weitere Informationen finden Sie in der Open-Source-Dokumentation zum Einfügen von Anmeldedaten für ausgehenden Traffic in Agent Substrate.

Standardmäßig blockiert Agent Substrate den gesamten ausgehenden Traffic zu anderen Akteuren, zur Kubernetes-Steuerungsebene, zum Compute Engine-Metadatenserver und zum Internet. Nicht-DNS-UDP, beliebige Raw-TCP-Verbindungen und HTTP-WebSocket-Upgrades werden blockiert. DNS löst nur Hostnamen auf, die von der EgressPolicy-Ressource des Akteurs zugelassen werden. Wenn Sie ausgehende Verbindungen zulassen möchten, definieren Sie HTTP-, HTTPS- oder TLS-Passthrough-Regeln in der EgressPolicy-Ressource mithilfe von voll qualifizierten Domainnamen (FQDNs) oder Platzhalter-Hostnamen. IP-Adressen und CIDR-Bereiche werden nicht unterstützt. Weitere Informationen finden Sie in der Open-Source-Dokumentation zu Agent Substrate für ausgehenden Traffic und Sicherheit.

Sitzungsprüfpunkte und Arbeitsbereichsspeicher

Wenn Ihre Anwendung einen Akteur (entweder in gVisor oder in MicroVMs) sperrt, speichert Agent Substrate einen Snapshot in Cloud Storage auf drei Ebenen: aktiver Speicher, Änderungen am Root-Dateisystem und langlebige Verzeichnisse (die Volume-Ebene). Alle angehängten externen CSI-Volumes bleiben auf ihrem Sicherungsspeicher außerhalb des Snapshots erhalten und werden beim Fortsetzen wieder angehängt.

Wenn ein gesperrter Akteur fortgesetzt wird, stellt Agent Substrate die höchste Snapshot-Ebene wieder her, die der Zielumgebung entspricht:

  • Arbeitsspeicher, Root-Dateisystem und Volumes: Werden in weniger als einer Sekunde wiederhergestellt, wenn der Akteur mit derselben Hardware, Sandbox-Laufzeit und demselben Container-Image fortfährt.
  • Root-Dateisystem und Volumes: Werden wiederhergestellt, wenn sich die Knotenhardware oder die Sandbox-Laufzeit ändert. Der Akteur startet seine Prozesse neu, behält aber die Änderungen am Root-Dateisystem und die langlebigen Verzeichnisse bei.
  • Nur Volumes: Werden wiederhergestellt, wenn Sie das Container-Image in der ActorTemplate-Ressource aktualisieren, während der Actor gesperrt ist. Bei der nächsten Fortsetzung werden die Container aus dem aktualisierten Image gestartet und langlebige Verzeichnisse und externe Volumes wiederhergestellt. Schreiben Sie Daten, die Image-Updates überstehen müssen, in langlebige Verzeichnisse oder externen Speicher.

Die Latenz beim Anhalten und Fortsetzen skaliert mit der Snapshot-Größe. Für große Arbeitsbereiche, die eine schnelle knotenübergreifende Wiederanbindung erfordern, wenn ein Akteur auf einem anderen Knoten fortgesetzt wird, sollten Sie externe Filestore-Agent-Volumes verwenden, anstatt die Daten im Snapshot zu speichern. Jedes externe CSI-Volume (Vorabversion) in einer ActorTemplate-Ressource wird exklusiv für einen einzelnen Actor bereitgestellt (nicht von mehreren Actoren gemeinsam genutzt) und mit diesem Actor gelöscht. Produktionssupport für Filestore-Agent-Volumes wird im Rahmen eines eingeschränkten GA-Programms angeboten, für das eine Zugriffsanfrage erforderlich ist.

Blockspeicher (z. B. Hyperdisk) wird für Knoten-Bootlaufwerke und lokales Snapshot-Caching verwendet, nicht für CSI-Volumes pro Akteur, da die Latenz beim Trennen und Anhängen von knotenübergreifenden Blöcken die Fortsetzung des Akteurs verlangsamt. Weitere Informationen finden Sie in der Open-Source-Dokumentation zu Agent Substrate-CSI-Volumes.

Pod-basiertes Modell: Agent Sandbox in der GKE

In der Agent Sandbox in GKE wird jeder Agent in einem dedizierten, zustandsorientierten Kubernetes-Pod ausgeführt, der über benutzerdefinierte Kubernetes-Ressourcen (Sandbox, SandboxClaim, SandboxTemplate und SandboxWarmPool) verwaltet wird. Eine SandboxWarmPool-Ressource verwaltet vorab aufgewärmte Sandbox-Ressourcen mit laufenden Pods für eine bestimmte SandboxTemplate-Ressource, sodass der Controller eine bereite Sandbox-Ressource und ihren laufenden Pod in weniger als einer Sekunde einer Anforderung zuweisen kann.

Wählen Sie Agent Sandbox aus, wenn jeder Agent einen dedizierten Pod benötigt oder wenn Ihre Arbeitslasten eine der folgenden Anforderungen haben:

  • Kontinuierlich aktive Agents und Dienste mit einem einzelnen Pod: Arbeitslasten ohne häufige Leerlaufzeiten oder persistente Sitzungen (z. B. Cloud-Entwicklungsumgebungen oder Jupyter Notebooks), die einen stabilen Hostnamen und Speicher ohne die Komplexität von StatefulSets benötigen.
  • Hardwarebeschleuniger (GPUs oder TPUs): Agenten, die direkten Zugriff auf GPUs oder TPUs in der Sandbox benötigen. Beschleuniger funktionieren nur mit der gVisor-Laufzeit auf unterstützten GPU-Modellen und TPU-Versionen. MicroVMs unterstützen keine GPUs oder TPUs.
  • Vollständige Kubernetes-PodSpec, Arm-Knoten oder GKE Autopilot: Arbeitslasten, die benutzerdefinierte Sidecar- oder Init-Container, Standard-Kubernetes-APIs und -Tools (z. B. kubectl-Befehle, rollenbasierte Zugriffssteuerung und vorhandene Controller), Arm-CPUs oder GKE Autopilot-Cluster erfordern.

Identitäts-, Anmeldedaten- und Netzwerkrichtlinien

Da jeder Agent in einem dedizierten Pod ausgeführt wird, können Sie dem Pod mithilfe der Workload Identity-Föderation für GKE oder der Agentenidentität (Vorschau) Google Cloud-IAM-Berechtigungen (Identity and Access Management) gewähren. Bei beiden Optionen wird die Identität beim Erstellen des Pods an das Kubernetes-ServiceAccount des Pods gebunden. Daher haben alle vorab initialisierten Pods in einer SandboxWarmPool-Ressource dieselbe Identität. Wenn Sie Identitäten pro Agent oder Mandant isolieren möchten, verwalten Sie eine separate SandboxWarmPool-Ressource pro Identität oder erstellen Sie Sandbox-Ressourcen bei Bedarf ohne Warmpool.

Sie stellen Secrets mithilfe von Standard-Kubernetes-Secret-Objekten oder CSI-Volumes in Pods bereit. Die Agent-Sandbox enthält kein Gateway für die Injektion von Anmeldedaten außerhalb der Sandbox. Wenn Sie Anmeldedaten während der Übertragung einfügen möchten, stellen Sie einen eigenen externen Proxy bereit.

Der Controller erstellt für jede SandboxTemplate-Ressource ein NetworkPolicy-Objekt mit der Standardeinstellung „Ablehnen“. Erstellen Sie für Sandbox-Ressourcen, die Sie direkt ohne Vorlage erstellen, ein eigenes NetworkPolicy-Objekt. Sie beschränken den Traffic mithilfe von Standard-GKE-Netzwerksteuerungen:

  • Ebene 4: Pod-zu-Pod- und IP-Traffic mit GKE-Netzwerkrichtlinien (NetworkPolicy-Objekte) einschränken.
  • Ebene 7: Beschränken Sie ausgehende Verbindungen auf genehmigte Domains mit FQDN-Netzwerkrichtlinien (FQDNNetworkPolicy-Objekte).

Inaktivitätssperre, Pod-Snapshots und Speicher

Der Pod eines inaktiven KI-Agenten behält seine reservierte CPU und seinen reservierten Arbeitsspeicher, bis Ihre Anwendung die Sandbox-Ressource sperrt, indem sie das Feld spec.operatingMode auf Suspended setzt. Durch das Sperren der Sandbox-Ressource wird der Pod gelöscht, während seine nichtflüchtigen Volumes beibehalten werden. Durch das Löschen des Pods werden die Daten im Arbeitsspeicher und die Änderungen am Containerdateisystem gelöscht. Wenn Sie diesen Status in Cloud Storage speichern und von dort wiederherstellen möchten, erstellen Sie einen GKE-Pod-Snapshot, bevor Sie den Agent sperren. Pod-Snapshots erfordern die gVisor-Laufzeit und unterstützen keine MicroVMs oder TPUs. Das Wiederherstellen eines Pods aus einem Snapshot dauert etwa drei bis fünf Sekunden.

Für nichtflüchtigen Speicher, der über Pod-Snapshots hinausgeht, stehen die folgenden Optionen zur Verfügung:

  • Filestore: Stellen Sie einen freigegebenen ReadWriteMany (RWX) PersistentVolumeClaim (PVC) in mehreren Sandbox-Pods für kollaborative Arbeitsbereiche bereit. Weitere Informationen finden Sie unter Speicher für KI-Agent-Arbeitslasten auswählen.
  • Hyperdisk: Verwenden Sie Google Cloud Hyperdisk Balanced (Zugriffsmodus ReadWriteOnce) für isolierte Pod-Laufwerke oder Google Cloud Hyperdisk ML (Zugriffsmodus ReadOnlyMany), um Lesezugriff-Datasets oder Modellgewichtungen knotenübergreifend freizugeben. Weitere Informationen finden Sie unter Speicher für KI-Agent-Arbeitslasten auswählen und Hyperdisk für GKE.

Agent Substrate und Agent Sandbox im Vergleich

In der folgenden Tabelle sind die architektonischen Unterschiede zwischen Agent Substrate in GKE und Agent Sandbox in GKE zusammengefasst:

Dimension Agent Substrate in der GKE (Akteur-basiert) Agent Sandbox in GKE (Pod-basiert)
Empfohlene Arbeitslasten für KI-Agenten Die meisten zustandsorientierten, CPU-basierten Agents, die häufig angehalten und fortgesetzt werden Kontinuierlich aktive Agents, GPU- oder TPU-Arbeitslasten, benutzerdefinierte PodSpecs, Arm-Knoten oder GKE Autopilot
Planungseinheit Mehrere Akteure teilen sich einen Pool von warmen Pods (WorkerPool) Ein dedizierter Pod pro Agent (Sandbox)
Sandbox-Laufzeiten gVisor- und Cloud Hypervisor-MicroVMs (werden in WorkerPool-Pods verwaltet) gVisor und MicroVMs in GKE Standard (mit aktivierter GKE Sandbox im Knotenpool oder in der ComputeClass) oder gVisor in GKE Autopilot (standardmäßig aktiviert)
Warm Pooling Gemeinsame WorkerPool-Ressourcen für Actor-Vorlagen und Container-Images Eine SandboxWarmPool-Ressource pro Vorlage und Container-Image
Pfad der Steuerungsebene Dedizierte Steuerungsebene und Datenbank außerhalb der kube-apiserver-Komponente Standard-Kubernetes-Controller, kube-apiserver und etcd
Umgang mit inaktiven Ressourcen Wenn ein inaktiver Akteur gesperrt wird, werden die CPU und der Arbeitsspeicher des Workers freigegeben. Wenn Sie eine inaktive Sandbox-Ressource sperren, wird ihr Pod gelöscht und nichtflüchtige Volumes werden beibehalten.
Statusprüfpunkte Integrierte Cloud Storage-Snapshots auf gVisor und MicroVMs, die in weniger als einer Sekunde wiederhergestellt werden GKE-Pod-Snapshots (nur in gVisor unterstützt), Wiederherstellung in 3–5 Sekunden
Unterstützte Clustermodi GKE Standard (Version 1.37 oder höher, x86-Knoten) GKE Standard und GKE Autopilot
Hardwarebeschleuniger Nicht unterstützt (nur CPU-Worker-Knoten) GPUs und TPUs werden nur mit der gVisor-Laufzeit unterstützt
Unterstützung für Kubernetes-PodSpec Teilmenge, die auf ActorTemplate- und WorkerPool-Ressourcen aufgeteilt ist Vollständige PodSpec, einschließlich Sidecars und Init-Containern
Netzwerk Integrierte Envoy-Ingress- und -Egress-Gateways mit mTLS-Tunneln pro Akteur Kubernetes-Dienste, NetworkPolicy und FQDNNetworkPolicy
Identitätsmodell SPIFFE-X.509-Zertifikat und JWT pro Akteur Pod-ServiceAccount, der die Workload Identity-Föderation für GKE oder die Agent-Identität (Vorschau) verwendet und über einen Warmpool freigegeben wird
Secret-Verwaltung Wird am Ausgangsgateway in ausgehende Anfragen eingefügt Im Pod mithilfe von Kubernetes-Secret-Objekten oder CSI-Volumes bereitgestellt

Sandbox-Laufzeit auswählen

Sowohl Agent Substrate als auch Agent Sandbox isolieren nicht vertrauenswürdigen Code vom Hostknoten mithilfe von Cloud Hypervisor-MicroVMs oder gVisor. Die Laufzeit wird jedoch in jedem Modell unterschiedlich konfiguriert:

  • Agent Substrate: Wählen Sie die Laufzeit für die WorkerPool-Ressource aus. Agent Substrate verwaltet seine eigenen MicroVM- und gVisor-Laufzeiten in seinen WorkerPool-Pods, anstatt die GKE Sandbox-Funktion auf Knotenebene zu verwenden. Aktivieren Sie GKE Sandbox nicht in Agent Substrate-Worker-Knotenpools, da die Knotenmarkierung sandbox.gke.io/runtime verhindert, dass WorkerPool-Pods geplant werden.
  • Agent Sandbox: Setzen Sie das Feld runtimeClassName in der Pod-Vorlage Ihrer SandboxTemplate-Ressource auf gvisor oder microvm. Aktivieren Sie in GKE Standard auch GKE Sandbox im Knotenpool oder in einer benutzerdefinierten ComputeClass. In GKE Autopilot ist gVisor standardmäßig verfügbar und MicroVMs werden nicht unterstützt.

In beiden Laufzeiten werden nicht vertrauenswürdiger Code und Headless-Browser ausgeführt:

  • MicroVMs: Jede Sandbox wird in einer einfachen virtuellen Maschine mit einem dedizierten Gast-Linux-Kernel ausgeführt. Wählen Sie MicroVMs, wenn Sie eine Isolierung auf VM-Ebene, vollständige Linux-Syscall-Kompatibilität oder CPU- und Arbeitsspeicherlimits pro Container innerhalb eines Multi-Container-Akteurs benötigen.
  • gVisor: Jede Sandbox wird in einem Userspace-Kernel ausgeführt, der Linux-Syscalls abfängt und filtert. Wählen Sie gVisor für schnellere Kaltstarts, geringeren Arbeitsspeicher-Overhead oder eine breitere Unterstützung von Compute Engine-Maschinen (einschließlich GPUs, TPUs, Arm-Knoten und GKE Autopilot in der Agent Sandbox).

In der folgenden Tabelle werden MicroVMs und gVisor in GKE verglichen:

Funktion MicroVMs gVisor
Kernel-Zugriff Vollständiger Linux-Kernel Teilmenge der Linux-Kernel-Syscalls
Isolationsebene Hardwarevirtualisierung mit einem dedizierten Gastkernel Syscall-Abfangen in einem Userspace-Kernel
CPU- und Arbeitsspeicher-Overhead VMM-Arbeitsspeicher pro Akteur in Agent Substrate. Festgelegt auf 250 mCPU und 130 MiB pro Pod in GKE Sandbox. Dynamischer Overhead mit geringem Basisspeicher
Beginn 1 bis 2 Sekunden Weniger als 100 ms
GKE-Knotenkonfiguration GKE-Standardknoten mit verschachtelter Virtualisierung (beide Modelle) oder x86-Bare-Metal-Knoten (nur Agent Substrate) GKE Standard-Knotenpools (beide Modelle) oder GKE Autopilot-Knoten (nur Agent Sandbox)
Unterstützung von Knoten-Images Container-Optimized OS (cos_containerd) in Agent Substrate. Container-Optimized OS (cos_containerd) oder Ubuntu in GKE Sandbox. Nur Container-Optimized OS (cos_containerd)
Kompatibilität von Maschinentypen x86-Maschinenserien, die verschachtelte Virtualisierung unterstützen, und x86-Bare-Metal (nicht unterstützt auf E2 oder Arm) Nicht gemischte x86-CPU-Serien in Agent Substrate. Die meisten x86-, Arm- und Beschleuniger-Serien in Agent Sandbox.
Beschleunigerunterstützung Nicht unterstützt Unterstützte GPU-Modelle und TPU-Versionen (nur Agent Sandbox)
Beispielanwendungsfälle
  • Autonome KI-Agenten für die Programmierung und Browser-Agenten
  • Arbeitslasten, die eine vollständige Linux-Kernel-Kompatibilität erfordern
  • Arbeitslasten mit hoher E/A-Leistung und häufigen Systemaufrufen
  • Nicht vertrauenswürdige Anwendungen in Python, Node.js, Go, Java oder Rust
  • CPU-, GPU- oder TPU-Inferenz und Sandboxes für die Codeausführung
  • Web-Frontends, Caches und Proxys

Weitere Informationen zu diesen Isolationstechnologien finden Sie unter GKE Sandbox.

Nächste Schritte