Automatyczna ocena kodu za pomocą piaskownicy agenta w GKE

1. Wprowadzenie

W tym ćwiczeniu wdrożysz aplikację Hackathon Judge w Google Kubernetes Engine (GKE) i użyjesz piaskownicy agentów Kubernetes-sigs do bezpiecznego uruchamiania zadań agentów.

Platforma została zaprojektowana z myślą o automatyzacji procesu sprawdzania, testowania i oceniania projektów z hackathonów za pomocą agentów LLM. Ocena wymaga sprawdzenia przesłanych przez uczestników kodów, które nie są zaufane, dlatego bezpieczna piaskownica wykonawcza ma kluczowe znaczenie w zapobieganiu wstrzykiwaniu kodu, eskalacji uprawnień i nadużywaniu zasobów.

Jakie zadania wykonasz

  • Zainicjuj docelowe usługi Google Cloud i ustal docelowe interfejsy API.
  • Zainicjuj Autopilota w GKE i zainstaluj definicje CRD piaskownicy agentów, konfiguracje klastra i router piaskownicy.
  • Wdróż bramę piaskownicy, szablon roszczenia piaskownicy i pulę wstępną piaskownicy.
  • Wdróż backend interfejsu REST API, agenta ADK Judging Worker i interfejs React Frontend UI.
  • Połącz zewnętrzne routingi z równoważeniem obciążenia i uzyskaj dostęp do platformy, aby uruchamiać bezpieczne, odizolowane przepływy pracy związane z ocenianiem.

Czego potrzebujesz

  • przeglądarka, np. Chrome;
  • projekt Google Cloud z włączonymi płatnościami;

Zasoby utworzone w tym laboratorium powinny kosztować mniej niż 5 USD w przypadku łącznych opłat za czas działania.

2. Problem: bezpieczne ocenianie niezaufanego kodu

Hackathony to szybkie wydarzenia innowacyjne, podczas których uczestnicy tworzą i przesyłają projekty – często zawierające kod źródłowy – do oceny. Ręczne ocenianie tych zgłoszeń jest czasochłonne i wymaga dużych nakładów pracy. Wykorzystanie agentów AI do automatyzacji oceniania to obiecujące rozwiązanie, ale wiąże się z poważnym problemem dotyczącym bezpieczeństwa: jak bezpiecznie uruchamiać kod dostarczony przez uczestników, który może zawierać błędy, być złośliwy lub wymagać dużych zasobów?

Uruchamianie niezaufanego kodu bezpośrednio w infrastrukturze naraża Cię na takie zagrożenia jak:

  • Wstrzykiwanie kodu: złośliwe skrypty mogą próbować uzyskać dostęp do danych wrażliwych lub je modyfikować.
  • Podniesienie uprawnień: kod może próbować uzyskać nieuprawniony dostęp do innych systemów lub zasobów sieciowych.
  • Nadużywanie zasobów: źle napisany kod lub ataki typu „odmowa usługi” mogą zużywać nadmierną ilość procesora, pamięci lub przepustowości sieci, co wpływa na inne operacje.

Aby zautomatyzować ocenianie hackathonu za pomocą AI, potrzebujemy sposobu na wykonywanie przesłanego kodu w środowisku całkowicie odizolowanym od reszty naszego systemu i innych zgłoszeń.

3. Rozwiązanie: piaskownica agentów GKE

Piaskownica agentów GKE to funkcja zaprojektowana specjalnie z myślą o tym wyzwaniu. Pomaga zarządzać izolowanymi, stanowymi i jednoreplikowymi zbiorami zadań w GKE. Jest zoptymalizowana pod kątem przypadków użycia, takich jak środowiska wykonawcze agentów AI, w których niezaufany kod musi być wykonywany bezpiecznie i wydajnie.

Najważniejsze zalety piaskownicy agenta:

  • Izolacja na poziomie jądra: zapewnia silną izolację na poziomie jądra w przypadku niezaufanego kodu za pomocą technologii takich jak gVisor, co uniemożliwia kodowi dostęp do systemu hosta lub innych kontenerów.
  • Provisioning w czasie poniżej sekundy: szybkie udostępnianie środowisk piaskownicy (zwykle <1 s), co ma kluczowe znaczenie w przypadku oceny kodu na żądanie.
  • Rozszerzalność natywna dla chmury: wykorzystuje potencjał Kubernetes i zarządzaną infrastrukturę GKE.

Dzięki Agent Sandbox możemy tworzyć na żądanie odizolowane środowiska dla każdego zgłoszenia na hackathon. Agent oceniający AI może następnie polecić piaskownicy agenta przeprowadzenie testów, skompilowanie kodu lub wykonanie innych kroków oceny w tej bezpiecznej piaskownicy bez ryzyka naruszenia integralności całej platformy. Zapewnia to skalowalny, bezpieczny i wydajny sposób na automatyzację oceniania hackathonów.

4. Zanim zaczniesz

Wybierz lub utwórz projekt

Sprawdź, czy pracujesz w odpowiednim projekcie Google Cloud:

  1. Wybierz lub utwórz projekt: wybierz istniejący projekt lub utwórz nowy w konsoli Google Cloud.
  2. Ustawianie aktywnego projektu: zanotuj identyfikator projektu, aby skonfigurować Cloud Shell do jego używania:
    gcloud config set project [YOUR_PROJECT_ID]
    

Weryfikacja płatności

Sprawdź, czy w projekcie Google Cloud włączone są płatności. Więcej informacji o tym, jak to zrobić, znajdziesz w tym przewodniku.

Uruchamianie Cloud Shell

Kliknij poniższy przycisk, aby uruchomić Google Cloud Shell, które jest wstępnie skonfigurowane z wymaganymi narzędziami wiersza poleceń dla programistów i usług w chmurze.

Włącz interfejsy API

Aby włączyć wszystkie docelowe interfejsy Cloud APIs Google Cloud wymagane do uruchomienia platformy, uruchom w Cloud Shell to polecenie:

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

Dlaczego włączamy te interfejsy API: usługi Google Cloud są domyślnie wyłączone, aby zapobiec nieautoryzowanemu dostępowi i obciążeniom. Włączamy te interfejsy API, aby aktywować orkiestrację kontenerów (GKE), bezpieczne przechowywanie kontenerów (Artifact Registry), bezserwerowe pakowanie kompilacji (Cloud Build), niezawodne kolejki wiadomości (Pub/Sub), usługi modeli AI (Vertex AI), konfigurację projektu (Cloud Resource Manager i IAM), bezserwerową analitykę danych (BigQuery) oraz powiązania AI na poziomie bazy danych (BigQuery Connection).

5. Konfigurowanie infrastruktury

W tym kroku sklonujesz repozytorium kodu i wykonasz automatyczny skrypt konfiguracji, aby wdrożyć docelową architekturę chmury i podstawowe komponenty klastra.

Klonowanie repozytorium

Sklonuj repozytorium zawierające wszystkie usługi aplikacji, skrypty konfiguracji i deklaracje manifestu Kubernetes:

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

Uruchamianie skryptu wdrożenia

Podstawowa konfiguracja zasobów w chmurze, modeli bazy danych i podstawowych zasad klastra Kubernetes jest zautomatyzowana przez skrypt deploy.sh.

Uruchom skrypt:

./deploy.sh

Postępuj zgodnie z instrukcjami w interaktywnej powłoce, aby podać konfiguracje, takie jak identyfikator aktywnego projektu i region docelowy. Skrypt automatycznie generuje lokalną konfigurację .env, wiąże zasoby, kompiluje obrazy kontenerów i rejestruje podstawową infrastrukturę GKE.

Oto operacje docelowe wykonywane przez skrypt:

1. Konfigurowanie środowiska

Skrypt tworzy plik konfiguracyjny .env do przechowywania parametrów zmiennych GKE, Pub/Sub, BigQuery i projektu. Dynamiczne pobieranie tego pliku wypełnia wszystkie kolejne definicje manifestu Kubernetes.

Dlaczego konfigurujemy ten plik środowiska: plik .env centralizuje parametry konfiguracji, dzięki czemu manifesty GKE, które zastosujemy ręcznie w kolejnych krokach, będą używać identycznych ustawień regionalnych, nazw projektów i zasobów, co ściśle oddziela konfigurację środowiska od kodu źródłowego.

2. Google Cloud CLI i konfiguracja projektu docelowego

Skrypt sprawdza, czy zainstalowane są narzędzia gcloud, bq, kubectl i envsubst, weryfikuje stan uwierzytelniania i blokuje aktywne środowiska docelowe konfiguracji w aktywnym projekcie w chmurze Google.

Dlaczego kierujemy reklamy na aktywny projekt: ustawienie aktywnego projektu docelowego zapobiega wpływaniu poleceń interfejsu wiersza poleceń na inne projekty na Twoim koncie i umożliwia przeprowadzenie wstępnych kontroli uwierzytelniania, dzięki czemu polecenia konfiguracji nie kończą się niepowodzeniem w trakcie wdrażania z powodu nieprawidłowych danych logowania.

3. Włączanie docelowych interfejsów Google Cloud API

Skrypt wykonuje idempotentne sprawdzenie, aby zweryfikować i włączyć interfejsy API docelowych usług Google Cloud (GKE, Artifact Registry, Cloud Build, Pub/Sub, Vertex AI, BigQuery i IAM).

Dlaczego włączamy interfejsy Google Cloud API: zarządzane usługi w chmurze muszą zostać aktywowane, zanim ich punkty końcowe staną się dostępne lub będzie można utworzyć zasoby. Włączenie ich na początku przygotowuje regionalną bramę interfejsu API GCP do obsługi kolejnych poleceń udostępniania zasobów.

4. Aprowizacja repozytorium Dockera w Artifact Registry

Skrypt udostępnia repozytorium kontenerów Dockera o nazwie hackathon-judge-repo w wybranej lokalizacji docelowej.

Dlaczego tworzymy repozytorium Artifact Registry: klastry GKE wymagają bezpiecznego dostępu do prywatnych rejestrów kontenerów w tej samej sieci regionalnej, aby szybko pobierać obrazy aplikacji. Artifact Registry to bezpieczny, prywatny host do katalogowania, skanowania i przechowywania obrazów kontenerów Dockera.

5. Provisioning the GKE Autopilot Cluster

Skrypt obsługuje klaster Autopilot w Google Kubernetes Engine (GKE) o nazwie hackathon-judge-cluster.

Dlaczego wdrażamy klaster GKE z Autopilotem: GKE Autopilot automatycznie zarządza udostępnianiem węzłów, skalowaniem, monitorowaniem stanu i uaktualnianiem zabezpieczeń systemu operacyjnego hosta. Zapewnia platformę kontenerową klasy produkcyjnej do orkiestracji naszych trwałych usług i dynamicznego planowania bezpiecznych piaskownic pracowników na żądanie.

6. Konfigurowanie tematów i subskrypcji Pub/Sub

Skrypt udostępnia tematy wiadomości (judging-tasksjudging-results) wraz z odpowiednimi subskrypcjami instancji roboczej i interfejsu API.

Dlaczego wdrażamy tematy i subskrypcje Pub/Sub: ocena przesłanych kodów jest powolna i wymaga dużych zasobów. Architektura kolejki komunikatów oddziela synchroniczny interfejs API dla użytkowników od węzłów roboczych. Backend interfejsu API przesyła zadania do tematu judging-tasks, a agenty robocze pobierają zadania, gdy są dostępne, co zapobiega blokowaniu interfejsu API i zapewnia automatyczne ponawianie.

7. Konfigurowanie zbiorów danych, tabel i połączeń AI w BigQuery

Skrypt tworzy hackathon_judge zbiór danych, stosuje strukturalne schematy bazy danych SQL, wczytuje rekordy początkowe i przyznaje wymagane role AI i pamięci masowej kontu usługi połączenia BigQuery ML.

8. Wywoływanie kompilacji kontenerów za pomocą Cloud Build

Skrypt wywołuje definicję cloudbuild.yaml, aby skompilować interfejs React, serwer REST w Go, proces roboczy Python ADK i piaskownicę FastAPI, spakować je w izolowane obrazy kontenerów oznaczone SHA zatwierdzenia Git aktywnego repozytorium i zapisać je w Artifact Registry.

9. Rejestrowanie definicji zasobów niestandardowych (CRD) piaskownicy agentów

Skrypt pobiera i rejestruje najnowsze definicje zasobów niestandardowych piaskownicy agentów Kubernetes-sigs (manifest.yaml i extensions.yaml), aby rozszerzyć podstawowe możliwości GKE.

Dlaczego instalujemy infrastrukturę piaskownicy agenta: standardowe klastry Kubernetes nie obsługują przydzielania chronionych piaskownic na żądanie. Rejestrowanie niestandardowych definicji zasobów piaskownicy agentów rozszerza platformę sterującą GKE, umożliwiając Kubernetesowi natywne zarządzanie bezpiecznymi mikrokontenerami w piaskownicy za pomocą zasobów niestandardowych (takich jak SandboxTemplates i SandboxClaims).

10. Konfigurowanie przestrzeni nazw, kont usługi i Workload Identity

Skrypt udostępnia przestrzeń nazw hackathon-judge, rejestruje konta usługi Kubernetes (KSA) i tworzy mapowania Workload Identity, aby przyznać zasobnikom GKE docelowe uprawnienia Google Cloud.

11. Wdrażanie routera piaskownicy

Skrypt stosuje manifest k8s/sandbox_router.yaml, inicjując wdrożenie i uruchomienie usługi Sandbox Router oraz czekając, aż osiągną one stan prawidłowego działania.

Dlaczego wdrażamy router piaskownicy: router piaskownicy to centralna wewnętrzna brama platformy sterującej. Udostępnia prosty interfejs API, który jest wywoływany przez agenta roboczego ADK w celu przejmowania, uzyskiwania dostępu do bezpiecznych piaskownic i zwalniania ich. Zarządza on mapowaniami routingu i oddziela alokację podów na poziomie klastra od logiki aplikacji.

6. Konfigurowanie bramy piaskownicy agentów, roszczeń i puli WarmPool

W tym kroku ręcznie skonfigurujesz specjalistyczną bramę sieci piaskownicy, zarejestrujesz szablon roszczenia piaskownicy i wdrożysz pulę wstępną piaskownicy, aby włączyć piaskownicę o bardzo małych opóźnieniach.

Zmienne środowiskowe źródła

Przed zastosowaniem szablonów wymagających zmiennych środowiskowych uruchom skrypt setup-env.sh, aby przeanalizować i wyeksportować wszystkie niezbędne zmienne do powłoki:

source ./setup-env.sh

Stosowanie bramy piaskownicy

Wdróż bramę skonfigurowaną specjalnie pod kątem kierowania ruchu z piaskownicy:

kubectl apply -f k8s/sandbox-gateway.yaml

Dlaczego wdrażamy bramę piaskownicy: brama piaskownicy działa jako bezpieczny kontroler wejścia o wysokiej wydajności, który jest przeznaczony wyłącznie do routingu w piaskownicy. Izoluje sieć piaskownicy, zapewniając bezpieczny, lokalny cel, który umożliwia agentom roboczym komunikowanie się z przejętymi piaskownicami bez udostępniania punktów końcowych na zewnątrz.

Zastosuj szablon roszczenia w piaskownicy

Użyj polecenia envsubst, aby wypełnić definicję szablonu piaskownicy aktywnymi zmiennymi środowiskowymi i zastosować ją:

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

Dlaczego wdrażamy szablon roszczenia piaskownicy: szablon roszczenia piaskownicy działa jako konfiguracja planu określająca środowisko. Określa obraz kontenera do uruchomienia (wstępnie spakowany z narzędziami dla programistów), parametry środowiska (identyfikator projektu GCP), porty i limity zasobów (docelowe wartości procesora i pamięci). Konfiguruje GKE do uruchamiania tych instancji kontenerów przy użyciu gVisor (środowiska wykonawczego gvisor), co gwarantuje, że niezaufany kod uczestnika jest uruchamiany pod dodatkową warstwą izolacji wirtualizacji jądra.

Stosowanie puli WarmPool w piaskownicy

Zastosuj WarmPool piaskownicy, aby wstępnie zainicjować działające piaskownice:

kubectl apply -f k8s/sandbox-warmpool.yaml

Sprawdź, czy instancje gotowości w puli wstępnego rozgrzewania zostały uruchomione:

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

Dlaczego wdrażamy pulę Sandbox WarmPool: udostępnianie, planowanie, pobieranie obrazów i uruchamianie nowych podów kontenerów na żądanie wiąże się ze znacznym narzutem na uruchomienie (czas uruchomienia „na zimno” wynosi ponad 30 sekund). Usługa Sandbox WarmPool utrzymuje pulę gotowości aktywnych, wstępnie przygotowanych podów piaskownicy (domyślnie 5 replik). Gdy agent roboczy poprosi o środowisko oceny, router piaskownicy natychmiast przydzieli uruchomiony, wstępnie rozgrzany zasobnik, skracając opóźnienia przy uruchamianiu do mniej niż sekundy.

7. Wdrażanie komponentów aplikacji

Po pełnym aktywowaniu bezpiecznej infrastruktury piaskownicy wdrożysz centralny backend interfejsu API, agenta roboczego, interfejs internetowy React i mapowanie bramy wejściowej.

Wdrażanie backendu

Wdróż backend interfejsu API REST aranżera:

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

Wdrażanie agenta

Wdróż agenta oceniającego ADK:

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

Wdrażanie frontendu

Wdróż interaktywny internetowy interfejs użytkownika:

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

Konfigurowanie zewnętrznej bramy i routingu

Wdróż główną bramę i trasy HTTP Ingress, które mapują ruch zewnętrznych klientów:

kubectl apply -f k8s/gateway.yaml

Dlaczego wdrażamy zewnętrzną bramę Ingress: zewnętrzna brama udostępnia nasze usługi za pomocą interfejsu Kubernetes Gateway API. Zapewnia on publiczny adres IP z równoważeniem obciążenia i mapuje trasy na podstawie reguł ścieżek – kieruje żądania API w /api/* do backendu Go i mapuje cały inny ruch internetowy klienta (/) na frontend React, zabezpieczając dostęp do klastra publicznego.

Weryfikowanie wdrożeń

Zablokuj wykonanie powłoki i poczekaj, aż wdrożenia wszystkich 3 usług podstawowych osiągną stan wdrożenia gotowy do użycia:

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. Weryfikacja i korzystanie z aplikacji

Dostęp do interfejsu

Pobierz zewnętrzny publiczny adres IP nowo utworzonej głównej bramy systemu równoważenia obciążenia:

Aby śledzić stan udostępniania w czasie rzeczywistym, uruchom polecenie z flagą watch (-w) i poczekaj, aż w polu ADDRESS pojawi się publiczny adres IP:

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

Po pomyślnym udostępnieniu powinny pojawić się dane wyjściowe podobne do tych:

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

Gdy w kolumnie ADDRESS zobaczysz prawidłowy publiczny adres IP, a stan PROGRAMMED będzie True, naciśnij Ctrl+C, aby zatrzymać zegarek.

Dlaczego otrzymujemy stan bramy: interfejs Gateway API obsługuje publiczny ruch przychodzący. Sprawdzenie stanu bramy zwraca publiczny, zrównoważony zewnętrzny adres IP przydzielony przez zewnętrzny globalny system równoważenia obciążenia Google Cloud do naszego klastra, który reprezentuje publiczny adres naszej platformy.

Otwórz przydzielony publiczny adres IP w przeglądarce, aby załadować panel sędziów hackathonu.

Przesyłanie zadań

  • W interfejsie użytkownika przejdź do panelu i wybierz hackathon.

Panel

  • W dowolnym projekcie możesz kliknąć Run Agent, aby rozpocząć ocenę całego projektu przez agenta na podstawie rubryki.

Projekty

Obejrzyj rozpoczęcie programu Sandbox

Monitoruj aktywne pody w przestrzeni nazw hackathon-judge, aby zobaczyć, jak pod piaskownicy jest dynamicznie przypisywany i udostępniany na potrzeby oceny wykonania:

kubectl get pods -n hackathon-judge -w

Sprawdź logi poda agenta instancji roboczej, aby zobaczyć krok po kroku logikę oceny ADK:

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

Dlaczego sprawdzamy logi agenta: sprawdzanie logów agenta pracownika wyświetla szczegółowe wewnętrzne kroki potoku oceny w czasie rzeczywistym. Możesz śledzić, jak agent ADK pobiera zadanie, wysyła prośbę o kontener piaskownicy, wykonuje cele kompilacji, analizuje raporty za pomocą Gemini i publikuje podsumowania statystyk.

9. (Opcjonalnie) Jak to działa

Architektura piaskownicy agentów

Funkcje AI w BigQuery są niezwykle przydatne do oceny zgłoszeń tekstowych i twierdzeń w plikach README, ale ocena projektu inżynieryjnego wymaga skompilowania kodu, zainstalowania bibliotek innych firm i uruchomienia rzeczywistych zestawów testów.

Uruchamianie nieprzetworzonego kodu użytkownika stwarza ogromne zagrożenia dla bezpieczeństwa, w tym naruszenie bezpieczeństwa hosta, wyjście z kontenera i nieautoryzowany dostęp do zasobów. Platforma GKE Agent Sandbox ogranicza te zagrożenia, organizując izolowane zadania w piaskownicy przy użyciu wirtualizacji gVisor (runsc).

Przebieg interakcji z systemem

Diagram poniżej pokazuje, jak różne elementy naszego systemu opartego na zdarzeniach komunikują się podczas bezpiecznego wykonywania oceny w środowisku piaskownicy:

Jak współpracują ze sobą zaangażowane narzędzia i komponenty

  • Interfejs React Frontend UI: udostępnia interaktywny interfejs, w którym użytkownicy mogą konfigurować modele kryteriów, rejestrować zespoły, przesyłać adresy URL projektów i sprawdzać ostateczne karty wyników, w tym pełne rozbieżności w plikach i komentarze inżynierów.
  • Go REST Backend API: zarządza globalnymi punktami końcowymi interfejsu API. Przechowuje konfiguracje projektów w BigQuery i przesyła zadania oceny do Pub/Sub, aby oddzielić potoki wykonywania obliczeń o dużej mocy.
  • Google Pub/Sub: broker zorientowany na wiadomości, który bezpiecznie przechowuje wiadomości o zadaniach w kolejce, asynchronicznie koordynując komunikację między interfejsem API a aktywnymi instancjami procesów roboczych.
  • Proces roboczy ADK w Pythonie (agent nadzorujący): proces działający w tle, który pobiera zadania z Pub/Sub. Korzysta on z pakietu Google Agent Development Kit (ADK), aby uruchomić agenta nadzorującego wyższego poziomu, który ma za zadanie koordynować ocenę. Nadzorca wywołuje swoje główne narzędzie evaluate_repository, aby delegować testowanie szczegółowych poleceń w formie surowej.
  • Router i brama piaskownicy (płaszczyzna sterowania GKE): wewnętrzna brama sterowania, która rejestruje standardowe definicje zasobów niestandardowych piaskownicy (SandboxClaims, SandboxTemplates). Koordynuje sieci GKE w celu przydzielania i zabezpieczania podów, zwracając strumienie połączeń do klientów roboczych.
  • Sandbox WarmPool: aby uniknąć długiego czasu uruchamiania kontenerów GKE („zimne starty” trwające ponad 30 sekund), WarmPool utrzymuje aktywne pody w trybie gotowości. Gdy piaskownica zostanie przejęta, router natychmiast mapuje ją w czasie poniżej sekundy, a następnie planuje jej odzyskanie po zwolnieniu.
  • Izolacja gVisor (runsc): wirtualne jądro przestrzeni użytkownika, które działa jako bezpieczna granica piaskownicy. Przechwytuje wywołania systemowe z przestrzeni kontenera do jąder węzłów GKE, zapewniając, że niebezpieczne polecenia pierwotne (takie jak skrypty systemowe lub konfiguracje pakietów) są uruchamiane w warunkach całkowitej izolacji wirtualizacji.
  • Środowisko wykonawcze Piaskownicy FastAPI: lekki serwer interfejsu API w Pythonie działający w kontenerze piaskownicy. Udostępnia bezpieczne punkty końcowe (/execute, /upload, /download), które umożliwiają zewnętrznym narzędziom roboczym manipulowanie plikami i wywoływanie zadań powłoki.
  • Interfejs wiersza poleceń Gemini (@google/gemini-cli): skrypt autonomicznego agenta zainstalowany w piaskownicy. Gdy jest wywoływany za pomocą flagi środowiska wykonawczego środowiska deweloperskiego (--yolo), korzysta z rygorystycznego arkusza instrukcji oceniania (prompt.md) i definicji kryteriów (criteria.md), aby:
    • Dynamicznie analizuj hierarchię bazy kodu (za pomocą narzędzi takich jak tree lub ripgrep).
    • automatycznie instalować wymagania (za pomocą poleceń takich jak npm install, pip install, go build);
    • Przeprowadzaj prawdziwe testy deweloperskie (np. npm test lub pytest), aby sprawdzić działanie.
    • Wywołuj modele Vertex AI (za pomocą danych logowania powiązanych z Workload Identity kontenera), aby oceniać logikę plików, sprawdzać twierdzenia w porównaniu z plikiem README, wykrywać nieistniejące funkcje, rejestrować problemy z jakością i zapisywać w evaluation.json raport z wynikami w formacie strukturalnym.
  • Standardowe środowiska deweloperskie: w obrazie kontenera piaskownicy znajdują się węzeł, npm, yarn, pnpm, python, pip, uv, go, gh, git, tree, ripgrep i playwright, co zapewnia autonomicznemu podagentowi kompletne środowisko testowe.

10. Czyszczenie

Aby uniknąć obciążenia konta Google Cloud bieżącymi opłatami, usuń zasoby utworzone podczas tego ćwiczenia.

./destroy.sh

Dlaczego zwalniamy miejsce w zasobach: Google Cloud rozlicza się na podstawie modelu wykorzystania zasobów. Aktywne zasoby, takie jak klastry GKE z Autopilotem, sieciowe systemy równoważenia obciążenia i dyski trwałe, generują bieżące opłaty nawet wtedy, gdy są nieaktywne. Wykonanie tego kroku spowoduje usunięcie przestrzeni nazw klastra w celu wyczyszczenia obiektów Kubernetes oraz usunięcie samego hosta klastra GKE Autopilot, aby natychmiast zakończyć naliczanie wszystkich opłat.

11. Gratulacje

Gratulacje! Udało Ci się wdrożyć aplikację Hackathon Judge z piaskownicą agentów w GKE.

Wdrożono bezpieczną, nowoczesną platformę AI opartą na zdarzeniach, która umożliwia testowanie i ocenianie przesłanych baz kodu pochodzących z niezaufanych źródeł w izolowanych kontenerach z ograniczeniami bezpieczeństwa.

Czego się nauczysz

  • Infrastruktura GKE: jak udostępniać GKE Autopilot i powiązane usługi Google Cloud, takie jak Pub/Sub i BigQuery.
  • Konfiguracja piaskownicy agentów: jak skonfigurować definicje zasobów niestandardowych, szablony piaskownicy, roszczenia piaskownicy i pule rozgrzewania piaskownicy o wysokiej wydajności.
  • Wdrażanie mikroserwisów: jak skonfigurować powiązania Workload Identity i wdrożyć architekturę mikroserwisów składającą się z wielu komponentów (Frontend React, REST Go, Worker ADK Agent i Isolated Sandbox).
  • Bezpieczna piaskownica: jak używać zwirtualizowanych kontenerów gVisor do bezpiecznego uruchamiania niezaufanych poleceń innych firm w węzłach GKE.

Dalsze kroki

Dokumentacja