Filestore-Agent-Volumes mit GKE Agent Substrate verwenden

Das Agent Substrate der Google Kubernetes Engine (GKE) ist eine Infrastrukturplattform, die den Lebenszyklus von zustandsorientierten KI-Agenten-Sandboxes verwaltet. Mit Agent Substrate können Plattformen inaktive KI-Agenten-Arbeitslasten sperren, um Rechenkosten zu sparen, und sie in weniger als einer Sekunde fortsetzen, wenn neue Prompts oder Aufgaben eingehen.

Filestore-Agent-Volumes bieten die nichtflüchtige Speicherebene für Agent Substrate und speichern Workspace-Dateien, Code-Repositories und Scratchpad-Artefakte über Sandbox-Aussetzungs- und Fortsetzungszyklen hinweg.

So verwendet Agent Substrate Agent Volumes

In den folgenden Schritten wird beschrieben, wie Agent Substrate und Filestore-Agent-Volumes einen interaktiven Coding-Agent unterstützen, der Entwickler beim Erstellen von Features, Ausführen von Tests und Debuggen von Code unterstützt:

  1. Sitzungsinitialisierung: Wenn ein Entwickler eine Aufgabe einreicht, erstellt Agent Substrate eine Sandbox-Umgebung in GKE und stellt ein dediziertes Filestore-Volume bereit. Der Agent klont das Projekt-Repository, installiert Abhängigkeiten und bereitet den Arbeitsbereich vor.
  2. Kosteneffiziente Inaktivitätsaussetzung: Während der Entwickler Codeunterschiede prüft oder den nächsten Prompt erstellt, hebt Agent Substrate die Bereitstellung des Volumes auf und beendet die Rechenumgebung. Die Auslastung der Rechenressourcen sinkt auf null, während alle Arbeitsbereichsdateien, der Git-Verlauf und die Build-Caches im Volume erhalten bleiben.
  3. Sofortige Fortsetzung: Wenn der Entwickler einen neuen Prompt sendet, beansprucht Agent Substrate eine vorgewärmte Sandbox und hängt das vorhandene Volume in weniger als 100 ms wieder an. Der Agent setzt die Arbeitslast sofort mit dem vollständigen Dateisystemkontext fort, sodass zeitaufwendige Repository-Klone oder Neuinstallationen von Abhängigkeiten vermieden werden.

Weitere Informationen finden Sie in der Dokumentation zu Agent Substrate.

Wenn Sie zustandsorientierte Agent-Arbeitslasten auf GKE Agent Substrate mit Filestore-Agent-Volumes ausführen möchten, installieren Sie Agent Substrate, konfigurieren die Integration des Filestore-CSI-Treibers und definieren Ihre Agent-Arbeitslasten so, dass sie dynamische CSI-Volumes verwenden.

Agent Substrate installieren

Wenn Sie Ihr Google Cloud -Projekt vorbereiten und Agent Substrate in einem GKE Standard-Cluster installieren möchten, folgen Sie der Anleitung unter Agent Substrate in GKE installieren.

Filestore-CSI-Treiber installieren und konfigurieren

Wenn Sie Filestore-Agent-Volumes mit Agent Substrate verwenden möchten, müssen Sie beim Ausführen des interaktiven Agent Substrate-Installationsprogramms den optionalen Schritt Filestore-CSI-Treiber auswählen.

Die Steuerungsebene von Agent Substrate (ateapi) kommuniziert direkt über gRPC mit dem Filestore-CSI-Treiber-Controller. Der CSI-Treiber stellt dynamisch Volumes pro Akteur aus Ihrem Filestore-Volume-Pool bereit, hängt sie an und trennt sie, synchron mit dem Lebenszyklus jedes Akteurs.

Arbeitslasten erstellen, die Filestore-Volumes verwenden

In Agent Substrate definieren Sie externe Filestore-Volumes deklarativ in einer ActorTemplate-Ressource, anstatt separate Kubernetes-PersistentVolumeClaim-Objekte zu erstellen. In den folgenden Schritten wird beschrieben, wie Sie eine Filestore-StorageClass und eine CSIDriverConfig konfigurieren, einen WorkerPool und einen ActorTemplate bereitstellen, die ein externes Filestore-Volume bereitstellen, und den Lebenszyklus des Akteurs verwalten.

StorageClass erstellen

Erstellen Sie eine Datei mit dem Namen storageclass.yaml, um dynamische Volumes aus Ihrem Filestore-Volume-Pool bereitzustellen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: substrate-volumepool-sc
provisioner: filestore.csi.storage.gke.io
parameters:
  volume-pool: "projects/PROJECT_ID/locations/LOCATION/volumePools/VOLUME_POOL_NAME"
allowVolumeExpansion: false
reclaimPolicy: Delete
volumeBindingMode: Immediate

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID in Google Cloud .
  • LOCATION: die Region, in der sich Ihr Volume-Pool befindet, z. B. us-central1.
  • VOLUME_POOL_NAME: der Name Ihres Filestore-Volume-Pools.

Wenden Sie den StorageClass an:

kubectl apply -f storageclass.yaml

CSIDriverConfig registrieren

Die Ressource CSIDriverConfig verbindet den Kubernetes-StorageClass-Bereitsteller (filestore.csi.storage.gke.io) mit dem gRPC-Netzwerkendpunkt des Filestore-CSI-Controller-Dienstes und dem lokalen Unix-Domain-Socket-Pfad des CSI-Knoten-Plug-ins.

Erstellen Sie eine Datei mit dem Namen csi-driver-config.yaml:

apiVersion: ate.dev/v1alpha1
kind: CSIDriverConfig
metadata:
  name: filestore.csi.storage.gke.io
spec:
  driverName: filestore.csi.storage.gke.io
  controllerEndpoint: tcp://csi-filestore-controller.gcp-filestore-csi-driver.svc:10000
  nodeSocketOverride: unix:///var/lib/kubelet/plugins/filestore.csi.storage.gke.io/csi.sock
  tls:
    enabled: true
    usePodIdentity: true
    serverName: csi-filestore-controller.gcp-filestore-csi-driver.svc

Wenden Sie den CSIDriverConfig an:

kubectl apply -f csi-driver-config.yaml

WorkerPool und ActorTemplate definieren

  1. Erstellen Sie den ate-demo-Atespace und den Kubernetes-Namespace, die als Isolationsgrenze für Ihren Worker-Pool, Ihre Actor-Vorlage und Ihre Actors dienen sollen:

    kubectl ate create atespace ate-demo
kubectl create namespace ate-demo

  2. Erstellen Sie eine WorkerPool-Ressource, um physische Standby-Arbeitslasten bereitzuhalten, die Akteur-Sandboxes hosten können. Speichern Sie das folgende Manifest als worker-pool.yaml:

    apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: agent-pool
  namespace: ate-demo
  labels:
    workload: stateful-agent
spec:
  replicas: 5
  workerImage: ko://github.com/agent-substrate/substrate/cmd/ateom-gvisor

  3. Wenden Sie das WorkerPool-Manifest an:

    kubectl apply -f worker-pool.yaml

  4. Erstellen Sie eine Datei mit dem Namen actor-template.yaml, in der der ActorTemplate definiert wird, der ein 5-GiB-Volume von substrate-volumepool-sc bereitstellt:

    metadata:
  atespace: ate-demo
  name: stateful-agent-template
workerSelector:
  matchLabels:
    workload: stateful-agent
containers:
- name: agent
  image: CONTAINER_IMAGE
  volumeMounts:
  - name: shared-storage
    mountPath: /mnt/shared
  readyz:
    httpGet:
      path: /readyz
      port: 8080
sandboxConfig:
  sandboxClass: SANDBOX_CLASS_GVISOR
  configName: gvisor-default
snapshotsConfig:
  storageLocation: gs://SNAPSHOT_BUCKET/stateful-agent
volumes:
- name: shared-storage
  externalVolumeTemplate:
    capacity: 5Gi
    storageClassName: substrate-volumepool-sc

    Ersetzen Sie Folgendes:

    • CONTAINER_IMAGE: das Container-Image für Ihre Agentenarbeitslast, z. B. gcr.io/my-project/agent-app@sha256:7f28ab0....
    • SNAPSHOT_BUCKET: der Cloud Storage-Bucket, der von Agent Substrate zum Speichern von Actor-Snapshots verwendet wird.

    In diesem Manifest gibt volumes[].externalVolumeTemplate die angeforderte Volume-Kapazität (5Gi) und die StorageClass (substrate-volumepool-sc) an, deren Bereitsteller mit Ihrer CSIDriverConfig übereinstimmt, während containers[].volumeMounts dieses Volume unter /mnt/shared bereitstellt. Jedes in volumes deklarierte Volume muss von mindestens einem Container bereitgestellt werden.

  5. Erstellen Sie den ActorTemplate über die Agent Substrate API mit der kubectl ate-CLI:

    kubectl ate create actor-template -f actor-template.yaml

Akteur erstellen, sperren und fortsetzen

Sobald der ActorTemplate erstellt und der Golden Snapshot bereit ist, können Sie eine Actor-Instanz erstellen und ihren Ausführungsstatus verwalten:

  1. Erstellen Sie einen neuen Akteur aus stateful-agent-template:

    kubectl ate create actor ACTOR_NAME \
    --template=stateful-agent-template \
    -a ate-demo

    Ersetzen Sie ACTOR_NAME durch einen DNS-1123-Labelnamen für Ihren Akteur, z. B. my-agent-1.

    Wenn Sie den Akteur erstellen, stellt Agent Substrate dynamisch ein dediziertes Filestore-Volume aus substrate-volumepool-sc bereit und stellt es unter /mnt/shared bereit.

  2. Akteur sperren, wenn er inaktiv wird:

    kubectl ate suspend actor ACTOR_NAME \
    -a ate-demo

    Wenn der Actor gesperrt wird, wird sein Speicherstatus in Cloud Storage gespeichert, das Filestore-Volume wird getrennt und die Bereitstellung wird aufgehoben. Dabei bleiben alle Arbeitsbereichsdateien auf dem Volume erhalten und die Arbeitslast wird freigegeben.

  3. Setzen Sie den Actor fort, wenn eine neue Anfrage oder Aufgabe eingeht:

    kubectl ate resume actor ACTOR_NAME \
    -a ate-demo

    Wenn der Actor fortgesetzt wird, wird er einer verfügbaren Arbeitslast zugewiesen, sein Speicher-Snapshot wird wiederhergestellt und das vorhandene Filestore-Volume wird unter /mnt/shared mit allen intakten Dateien wieder angehängt.

Nächste Schritte