Automatische Code-Evaluierung mit Agent Sandbox in GKE

1. Einführung

In diesem Codelab stellen Sie die Hackathon Judge-Anwendung in Google Kubernetes Engine (GKE) bereit und verwenden die Kubernetes-sigs Agent Sandbox, um Agent-Arbeitslasten sicher auszuführen.

Die Plattform wurde entwickelt, um den Prozess der Überprüfung, des Testens und der Bewertung von Hackathon-Projekten mithilfe von LLM-Agents zu automatisieren. Da bei der Bewertung nicht vertrauenswürdige Codebeiträge von Teilnehmern geprüft werden müssen, ist eine sichere Ausführungs-Sandbox unerlässlich, um Code-Injection, Rechteausweitung oder Ressourcenmissbrauch zu verhindern.

Aufgaben

  • Stellen Sie die Ziel-Google Cloud-Dienste bereit und richten Sie Ziel-APIs ein.
  • GKE Autopilot initialisieren und die Agent Sandbox-CRDs, Clusterkonfigurationen und den Sandbox-Router installieren.
  • Stellen Sie das Sandbox-Gateway, die Sandbox-Anspruchsvorlage und einen Sandbox-WarmPool bereit.
  • Stellen Sie die REST Backend API, den ADK Judging Worker-Agent und die React-Frontend-UI bereit.
  • Verbinden Sie externes Load-Balancing-Routing und greifen Sie auf die Plattform zu, um sichere, in einer Sandbox ausgeführte Bewertungs-Workflows auszuführen.

Voraussetzungen

  • Ein Webbrowser wie Chrome.
  • Google Cloud-Projekt mit aktivierter Abrechnungsfunktion.

Die in diesem Codelab erstellten Ressourcen sollten insgesamt weniger als 5 $ kosten.

2. Das Problem: Nicht vertrauenswürdigen Code sicher auswerten

Hackathons sind Innovationsveranstaltungen, bei denen die Teilnehmer Projekte entwickeln und zur Bewertung einreichen. Oftmals wird auch Quellcode eingereicht. Die manuelle Überprüfung dieser Einreichungen ist zeit- und ressourcenaufwendig. KI-Agenten zum Automatisieren der Benotung sind eine vielversprechende Lösung, stellen aber eine erhebliche Sicherheitsherausforderung dar: Wie kann man von Teilnehmern bereitgestellten Code sicher ausführen, der fehlerhaft, schädlich oder ressourcenintensiv sein könnte?

Wenn Sie nicht vertrauenswürdigen Code direkt auf Ihrer Infrastruktur ausführen, sind Sie folgenden Risiken ausgesetzt:

  • Code-Injection: Mit schädlichen Skripten könnte versucht werden, auf sensible Daten zuzugreifen oder diese zu ändern.
  • Rechteausweitung: Code versucht möglicherweise, unbefugten Zugriff auf andere Systeme oder Netzwerkressourcen zu erhalten.
  • Ressourcenmissbrauch: Schlecht geschriebener Code oder Denial-of-Service-Angriffe können übermäßig viel CPU, Arbeitsspeicher oder Netzwerkbandbreite verbrauchen und sich auf andere Vorgänge auswirken.

Um die Bewertung von Hackathons mit KI zu automatisieren, benötigen wir eine Möglichkeit, eingereichten Code in einer Umgebung auszuführen, die vollständig vom Rest unseres Systems und anderen Beiträgen isoliert ist.

3. Die Lösung: GKE Agent Sandbox

GKE Agent Sandbox wurde speziell für diese Herausforderung entwickelt. Damit lassen sich isolierte, zustandsorientierte und Single-Replica-Arbeitslasten in GKE verwalten. Außerdem ist die Sandbox für Anwendungsfälle wie KI-Agenten-Runtimes optimiert, bei denen nicht vertrauenswürdiger Code sicher und effizient ausgeführt werden muss.

Die wichtigsten Vorteile der Agent Sandbox:

  • Isolation auf Kernelebene: Bietet eine starke Isolation auf Kernelebene für nicht vertrauenswürdigen Code mithilfe von Technologien wie gVisor, wodurch verhindert wird, dass Code auf das Hostsystem oder andere Container zugreift.
  • Bereitstellung in weniger als einer Sekunde: Bietet eine schnelle Bereitstellung von Sandbox-Umgebungen (in der Regel <1 Sekunde), was für die On-Demand-Codeauswertung entscheidend ist.
  • Cloud-native Erweiterbarkeit: Nutzt die Leistungsfähigkeit von Kubernetes und die verwaltete Infrastruktur von GKE.

Mit der Agent Sandbox können wir für jeden Hackathon-Beitrag isolierte On-Demand-Umgebungen erstellen. Der KI-Bewertungs-Agent kann dann Agent Sandbox anweisen, Tests auszuführen, Code zu kompilieren oder andere Bewertungsschritte in dieser sicheren Sandbox durchzuführen, ohne die Integrität der gesamten Plattform zu gefährden. So können Sie die Bewertung von Hackathons skalierbar, sicher und effizient automatisieren.

4. Vorbereitung

Cloud Shell starten

Klicken Sie auf den Button unten, um Google Cloud Shell zu starten. Diese ist mit den erforderlichen Befehlszeilenprogrammen für Entwickler und Cloud vorkonfiguriert.

APIs aktivieren

Führen Sie den folgenden Befehl in Cloud Shell aus, um alle Google Cloud-Ziel-Cloud APIs zu aktivieren, die zum Ausführen der Plattform erforderlich sind:

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

Warum wir diese APIs aktivieren:Google Cloud-Dienste sind standardmäßig deaktiviert, um unbefugten Zugriff und unbefugte Belastungen zu verhindern. Wir aktivieren diese spezifischen APIs, um Container-Orchestrierung (GKE), sichere Containerspeicherung (Artifact Registry), serverloses Build-Packaging (Cloud Build), zuverlässige Messaging-Warteschlangen (Pub/Sub), KI-Modelldienste (Vertex AI), Projektkonfiguration (Cloud Resource Manager und IAM), serverlose Datenanalyse (BigQuery) und KI-Bindungen auf Datenbankebene (BigQuery-Verbindung) zu ermöglichen.

5. Infrastruktur einrichten

In diesem Schritt klonen Sie das Code-Repository und führen das automatisierte Setupskript aus, um die Ziel-Cloudarchitektur und die Baseline-Clusterkomponenten bereitzustellen.

Repository klonen

Klonen Sie das Repository mit allen Anwendungsdiensten, Einrichtungs-Scripts und Kubernetes-Manifestdeklarationen:

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

Bereitstellungsskript ausführen

Die grundlegende Einrichtung Ihrer Cloudressourcen, Datenbankmodelle und Kubernetes-Clusterrichtlinien wird durch das Skript deploy.sh automatisiert.

Führen Sie das Script aus:

./deploy.sh

Folgen Sie den interaktiven Shell-Aufforderungen, um Konfigurationen wie Ihre aktive Projekt-ID und Zielregion anzugeben. Das Skript generiert automatisch eine lokale .env-Konfiguration, bindet Ressourcen, kompiliert Container-Images und registriert die GKE-Basisinfrastruktur.

Das Skript führt die folgenden Zielvorgänge aus:

1. Umgebungskonfiguration einrichten

Das Skript erstellt eine .env-Konfigurationsdatei zum Speichern von GKE-, Pub/Sub-, BigQuery- und Projektvariablenparametern. Durch das dynamische Sourcing dieser Datei werden alle nachfolgenden Kubernetes-Manifestdefinitionen ausgefüllt.

Warum wir diese Umgebungsvariable konfigurieren:In der Datei .env werden Konfigurationsparameter zentralisiert. So wird sichergestellt, dass die GKE-Manifeste, die wir in den folgenden Schritten manuell anwenden, identische regionale Einstellungen, Projektnamen und Ressourcen verwenden. Die Umgebungskonfiguration wird strikt vom Quellcode entkoppelt.

2. Google Cloud CLI- und Zielprojektkonfiguration

Das Skript prüft, ob die Dienstprogramme gcloud, bq, kubectl und envsubst installiert sind, prüft den Authentifizierungsstatus und sperrt aktive Konfigurationsziele für Ihr aktives Google Cloud-Projekt.

Warum wir das aktive Projekt als Ziel verwenden:Wenn Sie das aktive Zielprojekt festlegen, wirken sich CLI-Befehle nicht auf andere Projekte in Ihrem Konto aus. Außerdem werden vorab Authentifizierungsprüfungen durchgeführt, damit Einrichtungsbefehle nicht aufgrund ungültiger Anmeldedaten während der Bereitstellung fehlschlagen.

3. Google Cloud APIs als Ziel aktivieren

Das Skript führt eine idempotente Prüfung durch, um die Ziel-APIs für Google Cloud-Dienste (GKE, Artifact Registry, Cloud Build, Pub/Sub, Vertex AI, BigQuery und IAM) zu prüfen und zu aktivieren.

Warum wir Google Cloud APIs aktivieren:Verwaltete Clouddienste müssen aktiviert werden, bevor ihre Endpunkte erreichbar sind oder Ressourcen erstellt werden können. Wenn Sie sie am Anfang aktivieren, ist das regionale GCP API-Gateway bereit, nachfolgende Befehle zur Ressourcenbereitstellung zu verarbeiten.

4. Artifact Registry-Docker-Repository bereitstellen

Das Skript stellt ein Docker-Container-Repository mit dem Namen hackathon-judge-repo am ausgewählten Zielort bereit.

Warum wir ein Artifact Registry-Repository erstellen:GKE-Cluster benötigen sicheren Zugriff auf private Container-Registries im selben regionalen Netzwerk, um Anwendungs-Images schnell abzurufen. Artifact Registry bietet einen sicheren, privaten Host zum Katalogisieren, Scannen und Speichern von Docker-Container-Images.

5. GKE Autopilot-Cluster bereitstellen

Mit dem Skript wird ein GKE-Autopilot-Cluster (Google Kubernetes Engine) mit dem Namen hackathon-judge-cluster bereitgestellt.

Warum wir einen GKE Autopilot-Cluster bereitstellen:GKE Autopilot verwaltet die Knotenbereitstellung, Skalierung, Systemdiagnose und Sicherheitsupgrades des Hostbetriebssystems automatisch. Sie bietet eine Containerplattform auf Produktionsniveau, um unsere persistenten Dienste zu orchestrieren und sichere Worker-Sandboxes dynamisch nach Bedarf zu planen.

6. Pub/Sub-Themen und -Abos konfigurieren

Das Script stellt die Nachrichtenthemen (judging-tasks und judging-results) zusammen mit den entsprechenden Worker- und API-Abos bereit.

Warum wir Pub/Sub-Themen und ‑Abos bereitstellen:Die Bewertung von Code-Einsendungen ist langsam und ressourcenintensiv. Durch die Verwendung einer Message-Queue-Architektur wird die synchrone, nutzerorientierte API von Worker-Knoten entkoppelt. Das API-Backend pusht Jobs an das judging-tasks-Thema und Worker-Agents rufen Aufgaben ab, sobald sie verfügbar sind. So wird ein Blockieren der API verhindert und es gibt automatische Wiederholungsfunktionen.

7. BigQuery-Datasets, -Tabellen und KI-Verbindungen konfigurieren

Das Skript erstellt das Dataset hackathon_judge, wendet strukturelle SQL-Datenbankschemas an, lädt Seed-Datensätze und gewährt dem Dienstkonto der BigQuery ML-Verbindung die erforderlichen KI- und Speicherrollen.

8. Container-Builds mit Cloud Build auslösen

Das Script löst die cloudbuild.yaml-Definition aus, um unsere React-Benutzeroberfläche, den Go-REST-Server, den Python-ADK-Worker und die FastAPI-Sandbox zu kompilieren. Sie werden in isolierte Container-Images verpackt, die mit der aktiven Repository-Git-Commit-SHA getaggt und in Artifact Registry gespeichert werden.

9. Benutzerdefinierte Ressourcendefinitionen (CRDs) für die Agent Sandbox registrieren

Das Skript lädt die neuesten benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) für die Kubernetes-sigs Agent Sandbox (manifest.yaml und extensions.yaml) herunter und registriert sie, um die Kernfunktionen von GKE zu erweitern.

Warum wir die Agent Sandbox-Infrastruktur installieren:Standard-Kubernetes-Cluster unterstützen die Zuweisung geschützter On-Demand-Sandboxes nicht. Durch die Registrierung von Agent Sandbox-CRDs wird die Steuerungsebene von GKE erweitert. So kann Kubernetes sichere Sandbox-Mikrocontainer mithilfe von benutzerdefinierten Ressourcen (z. B. SandboxTemplates und SandboxClaims) nativ orchestrieren.

10. Namespaces, Dienstkonten und Workload Identity konfigurieren

Das Skript stellt den Namespace hackathon-judge bereit, registriert Kubernetes-Dienstkonten (Kubernetes Service Accounts, KSAs) und richtet Workload Identity-Zuordnungen ein, um GKE-Pods die erforderlichen Google Cloud-Berechtigungen zu gewähren.

11. Sandbox-Router bereitstellen

Das Skript wendet das k8s/sandbox_router.yaml-Manifest an, wodurch die Bereitstellung des Sandbox-Routers und des Dienstes initiiert wird. Anschließend wird gewartet, bis sie den Status „Fehlerfrei“ erreichen.

Warum wir den Sandbox-Router bereitstellen:Der Sandbox-Router ist das zentrale interne Gateway für die Steuerungsebene. Es stellt eine einfache API bereit, die vom ADK-Bewertungs-Worker-Agent aufgerufen wird, um sichere Sandboxes zu beanspruchen, darauf zuzugreifen oder sie freizugeben. Außerdem werden Routingzuordnungen verwaltet und die Pod-Zuweisung auf Clusterebene von der Anwendungslogik abstrahiert.

6. Agent Sandbox Gateway, Claims und WarmPool konfigurieren

In diesem Schritt konfigurieren Sie das Gateway für das spezielle Sandbox-Netzwerk manuell, registrieren die Sandbox-Anspruchsvorlage und stellen den Sandbox-WarmPool bereit, um die Sandbox mit extrem niedriger Latenz zu aktivieren.

Quellumgebungsvariablen

Bevor Sie Vorlagen anwenden, für die Umgebungsvariablen erforderlich sind, führen Sie das setup-env.sh-Skript aus, um alle erforderlichen Variablen in Ihre Shell zu parsen und zu exportieren:

source ./setup-env.sh

Sandbox-Gateway anwenden

Stellen Sie das Gateway bereit, das speziell für das Routing von Sandbox-Traffic konfiguriert ist:

kubectl apply -f k8s/sandbox-gateway.yaml

Warum wir das Sandbox-Gateway bereitstellen:Das Sandbox-Gateway fungiert als sicherer, leistungsstarker Ingress-Controller, der ausschließlich für das Sandbox-Routing vorgesehen ist. Dadurch wird das Sandbox-Netzwerk isoliert und ein sicheres, lokales Ziel bereitgestellt, über das Worker-Agents mit beanspruchten Sandboxes kommunizieren können, ohne Endpunkte extern freizugeben.

Sandbox-Antragsvorlage anwenden

Verwenden Sie envsubst, um die Sandbox-Vorlagendefinition mit Ihren aktiven Umgebungsvariablen zu füllen und anzuwenden:

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

Warum wir die Sandbox-Anspruchsvorlage bereitstellen:Die Sandbox-Anspruchsvorlage dient als Blueprint-Konfiguration, die die Umgebung definiert. Sie gibt das auszuführende Container-Image (mit vorinstallierten Entwicklertools), Umgebungsparameter (GCP-Projekt-ID), Ports und Ressourcenlimits (CPU-/Arbeitsspeicherziele) an. Damit wird GKE so konfiguriert, dass diese Containerinstanzen mit gVisor (gvisor-Laufzeit) ausgeführt werden. So wird sichergestellt, dass nicht vertrauenswürdiger Teilnehmercode unter einer zusätzlichen Ebene der Kernel-Virtualisierungsisolation ausgeführt wird.

Sandbox-WarmPool anwenden

Wenden Sie den Sandbox-WarmPool an, um laufende Sandboxen vorzuinitialisieren:

kubectl apply -f k8s/sandbox-warmpool.yaml

Prüfen Sie, ob die Standby-Instanzen des Warmpools erfolgreich gestartet wurden:

kubectl get pods -n hackathon-judge -l app=sandbox

Warum wir den Sandbox-WarmPool bereitstellen:Das Bereitstellen, Planen, Abrufen von Images und Booten neuer Container-Pods auf Anfrage führt zu einem erheblichen Start-Overhead (Kaltstartzeiten von mehr als 30 Sekunden). Der Sandbox-WarmPool verwaltet einen Stand-by-Pool mit aktiven, vorab aufgewärmten Sandbox-Pods (standardmäßig 5 Repliken). Wenn der Worker-Agent eine Testumgebung anfordert, weist der Sandbox-Router sofort einen laufenden, vorab aufgewärmten Pod zu. Dadurch werden Startverzögerungen auf weniger als eine Sekunde reduziert.

7. Anwendungskomponenten bereitstellen

Nachdem die sichere Sandbox-Infrastruktur vollständig aktiviert ist, stellen Sie die zentrale Backend-API, den Worker-Agent, die React-Weboberfläche und die Ingress-Gateway-Zuordnung bereit.

Backend bereitstellen

Orchestrator-REST API-Backend bereitstellen:

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

KI-Agent bereitstellen

ADK-Worker-Agent für die Bewertung bereitstellen:

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

Frontend bereitstellen

Interaktive Weboberfläche bereitstellen:

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

Externes Gateway und Routing konfigurieren

Stellen Sie das Haupt-Gateway und die HTTP-Ingress-Routen bereit, die externen Client-Traffic zuordnen:

kubectl apply -f k8s/gateway.yaml

Warum wir das externe Ingress Gateway bereitstellen:Das externe Gateway stellt unsere Dienste über die Kubernetes Gateway API bereit. Es wird eine Load-Balanced-öffentliche IP-Adresse bereitgestellt und Routen werden anhand von Pfadregeln zugeordnet. API-Anfragen unter /api/* werden an das Go-Backend weitergeleitet und der gesamte andere Client-Web-Traffic (/) wird dem React-Frontend zugeordnet. So wird der öffentliche Clusterzugriff gesichert.

Roll-outs prüfen

Blockieren Sie die Shell-Ausführung und warten Sie, bis alle drei Core-Service-Bereitstellungen einen fehlerfreien, bereit für die Einführung-Status erreicht haben:

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

8. Anwendung bestätigen und verwenden

Zugriff auf die Benutzeroberfläche

Rufen Sie die externe öffentliche IP-Adresse des neu bereitgestellten Haupt-Load-Balancer-Gateways ab:

Wenn Sie den Bereitstellungsstatus in Echtzeit beobachten möchten, führen Sie den Befehl mit dem Flag „watch“ (-w) aus und warten Sie, bis im Feld ADDRESS eine öffentliche IP-Adresse angezeigt wird:

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

Wenn die Bereitstellung erfolgreich war, sollte die Ausgabe in etwa so aussehen:

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

Sobald in der Spalte ADDRESS eine gültige öffentliche IP-Adresse angezeigt wird und der Status PROGRAMMED True lautet, drücke Ctrl+C, um die Smartwatch zu stoppen.

Warum wir den Gateway-Status abrufen:Die Gateway API verarbeitet öffentlichen Ingress. Wenn Sie den Gateway-Status prüfen, wird die öffentliche, per Load-Balancing verteilte externe IP-Adresse zurückgegeben, die vom externen globalen Load Balancer von Google Cloud unserem Cluster zugewiesen wurde. Diese Adresse stellt die öffentliche Adresse unserer Plattform dar.

Öffnen Sie die zugewiesene öffentliche IP-Adresse in Ihrem Browser, um das Hackathon Judge-Dashboard zu laden.

Aufgaben einreichen

  • Rufen Sie das Dashboard über die Frontend-Benutzeroberfläche auf und wählen Sie den Hackathon aus.

Dashboard

  • Klicken Sie in einem beliebigen Projekt auf Run Agent, um den Agenten das gesamte Projekt anhand der Rubrik bewerten zu lassen.

Projekte

Sandbox-Kickoff ansehen

Beobachten Sie die aktiven Pods im Namespace hackathon-judge, um zu sehen, wie ein Sandbox-Pod dynamisch beansprucht und für die Ausführung bereitgestellt wird:

kubectl get pods -n hackathon-judge -w

Sehen Sie sich die Logs des Worker-Agent-Pods an, um die schrittweise ADK-Bewertungslogik zu sehen:

kubectl logs -l app=agent -n hackathon-judge

Warum wir Agent-Logs prüfen:Durch die Prüfung von Worker-Agent-Logs werden die detaillierten internen Schritte der Evaluierungspipeline in Echtzeit angezeigt. Sie können nachvollziehen, wie der ADK-Agent die Aufgabe abruft, einen Sandbox-Container anfordert, Kompilierungsziele ausführt, Berichte mit Gemini analysiert und Kurzübersichten veröffentlicht.

9. (Optional) Funktionsweise

Architektur der Agent Sandbox

BigQuery-KI-Funktionen sind zwar hervorragend geeignet, um textbasierte Einsendungen und README-Behauptungen zu bewerten, für die Beurteilung eines Engineering-Projekts ist jedoch das Kompilieren von Code, die Installation von Drittanbieterbibliotheken und das Ausführen von echten Testsuiten erforderlich.

Die Ausführung von rohem Nutzercode birgt massive Sicherheitsrisiken, darunter Host-Compromising, Container-Breakouts und unbefugten Ressourcenzugriff. Das GKE Agent Sandbox-Framework minimiert diese Risiken, indem es isolierte Sandbox-Arbeitslasten mithilfe von gVisor (runsc)-Virtualisierung orchestriert.

Systeminteraktionsablauf

Das folgende Diagramm zeigt, wie die verschiedenen Elemente unseres ereignisgesteuerten Systems während einer sicheren Sandbox-Ausführung kommunizieren:

Zusammenwirken von Tools und Komponenten

  • React-Frontend-UI: Bietet eine interaktive Oberfläche, auf der Nutzer Kriterienmodelle konfigurieren, Teams registrieren, Projekt-URLs einreichen und endgültige Bewertungskarten mit vollständigen Dateidifferenzen und technischen Kommentaren einsehen können.
  • Go REST Backend API: Verwaltet globale API-Endpunkte. Darin werden Projektkonfigurationen in BigQuery gespeichert und Bewertungsjobs an Pub/Sub gesendet, um rechenintensive Ausführungspipelines zu entkoppeln.
  • Google Pub/Sub: Der nachrichtenorientierte Broker, der Aufgabenbenachrichtigungen sicher in der Warteschlange hält und die asynchrone Kommunikation zwischen der API und aktiven Worker-Instanzen orchestriert.
  • Python ADK Worker (Supervisor-Agent): Ein Hintergrundworker, der Aufgaben aus Pub/Sub abruft. Dabei wird das Google Agent Development Kit (ADK) verwendet, um einen Supervisor-Agenten auf hoher Ebene zu starten, der die Orchestrierung der Bewertung übernimmt. Der Supervisor ruft sein primäres Tool evaluate_repository auf, um das Testen von Rohbefehlen zu delegieren.
  • Sandbox-Router und ‑Gateway (GKE-Steuerungsebene): Ein internes Steuerungs-Gateway, in dem standardmäßige Sandbox-CRDs (SandboxClaims, SandboxTemplates) registriert werden. Es koordiniert GKE-Netzwerke, um Pods zuzuweisen und zu schützen, und gibt Verbindungsstreams an Worker-Clients zurück.
  • Sandbox WarmPool: Um lange GKE-Container-Startzeiten („Kaltstarts“ von mehr als 30 Sekunden) zu vermeiden, werden im WarmPool aktive Standby-Pods verwaltet. Wenn eine Sandbox beansprucht wird, wird sie vom Router sofort in weniger als einer Sekunde zugeordnet und dann für die Wiederverwendung nach der Freigabe geplant.
  • gVisor-Isolation (runsc): Ein virtueller Kernel im Nutzerbereich, der als sichere Sandbox-Grenze fungiert. Es fängt Systemaufrufe vom Containerbereich an GKE-Knotenkerneln ab und sorgt dafür, dass gefährliche Rohbefehle (z. B. Systemskripts oder Paketeinrichtungen) unter absoluter Virtualisierungsisolation ausgeführt werden.
  • FastAPI Sandbox Runtime: Ein einfacher Python-API-Server, der im Sandbox-Container ausgeführt wird. Es werden sichere Endpunkte (/execute, /upload, /download) bereitgestellt, mit denen externe Worker-Tools Dateien bearbeiten und Shell-Aufgaben auslösen können.
  • Gemini CLI (@google/gemini-cli): Ein autonomes Agent-Script, das in der Sandbox installiert ist. Wenn sie mit dem Laufzeit-Flag für die Entwicklerumgebung (--yolo) ausgelöst wird, werden ein strenges Bewertungsanleitung (prompt.md) und eine Kriteriendefinition (criteria.md) verwendet, um Folgendes zu tun:
    • Codebasis-Hierarchie dynamisch analysieren (mit Tools wie tree oder ripgrep).
    • Anforderungen automatisch installieren (über Befehle wie npm install, pip install, go build).
    • Führen Sie echte Entwicklungstests aus, z. B. npm test oder pytest, um die Funktionalität zu prüfen.
    • Rufen Sie Vertex AI-Modelle (über die Workload Identity-Bindungsanmeldedaten des Containers) auf, um die Dateilogik zu bewerten, Behauptungen mit der README-Datei abzugleichen, Ghost-Funktionen zu erkennen, Qualitätsprobleme zu protokollieren und einen strukturierten Scorecard-Bericht in evaluation.json zu schreiben.
  • Standard-Entwicklungsumgebungen: Bündelt Node, npm, Yarn, pnpm, Python, pip, uv, Go, gh, Git, Tree, ripgrep und Playwright im Sandbox-Container-Image und bietet dem autonomen Sub-Agent einen vollständigen Testarbeitsbereich.

10. Bereinigen

Löschen Sie die in diesem Codelab erstellten Ressourcen, um laufende Gebühren für Ihr Google Cloud-Konto zu vermeiden.

./destroy.sh

Warum bereinigen wir Ressourcen? Die Abrechnung in Google Cloud erfolgt auf Grundlage der Ressourcennutzung. Für aktive Ressourcen wie GKE Autopilot-Cluster, Network Load Balancer und nichtflüchtige Speicher fallen laufende Gebühren an, auch wenn sie inaktiv sind. Bei diesem Schritt wird der Clusternamespace gelöscht, um Kubernetes-Objekte zu entfernen, und der GKE Autopilot-Clusterhost selbst wird gelöscht, um alle zugrunde liegenden Abrechnungsgebühren sofort zu beenden.

11. Glückwunsch

Glückwunsch! Sie haben die Hackathon Judge-Anwendung mit Agent Sandbox in GKE erfolgreich bereitgestellt.

Sie haben eine sichere, moderne ereignisgesteuerte KI-Plattform implementiert, mit der Sie nicht vertrauenswürdige Codebase-Einreichungen unter isolierten, containerisierten Sicherheitsbeschränkungen testen und bewerten können.

Das haben Sie gelernt

  • GKE-Infrastruktur: Hier erfahren Sie, wie Sie GKE Autopilot und unterstützende Google Cloud-Dienste wie Pub/Sub und BigQuery bereitstellen.
  • Agent Sandbox Configuration: Hier erfahren Sie, wie Sie benutzerdefinierte Ressourcendefinitionen, SandboxTemplates, SandboxClaims und leistungsstarke Sandbox-WarmPools konfigurieren.
  • Bereitstellung von Mikrodiensten: Hier erfahren Sie, wie Sie Workload Identity-Bindungen konfigurieren und eine Mikrodienstarchitektur mit mehreren Komponenten (Frontend React, REST Go, Worker ADK Agent und Isolated Sandbox) bereitstellen.
  • Sichere Sandbox: Hier erfahren Sie, wie Sie virtualisierte gVisor-Container verwenden, um nicht vertrauenswürdige Befehle von Drittanbietern sicher auf GKE-Knoten auszuführen.

Nächste Schritte

Referenzdokumente