הערכה אוטומטית של קוד באמצעות ארגז חול לסוכנים ב-GKE

1. מבוא

ב-Codelab הזה תפרסו את האפליקציה Hackathon Judge ב-Google Kubernetes Engine ‏ (GKE) ותשתמשו בארגז החול לסוכנים של Kubernetes-sigs כדי להריץ עומסי עבודה של סוכנים בצורה בטוחה ומאובטחת.

הפלטפורמה נועדה לאוטומציה של תהליך הבדיקה, הבחינה והדירוג של פרויקטים במרתון תכנות באמצעות סוכני LLM. השיפוט מחייב הערכה של קוד לא מהימן שנשלח על ידי המשתתפים, ולכן ארגז חול (Sandbox) מאובטח להרצת קוד הוא חיוני כדי למנוע הזרקת קוד, הרחבת הרשאות או שימוש לרעה במשאבים.

הפעולות שתבצעו:

  • הקצאת שירותי Google Cloud ליעד והגדרת ממשקי API ליעד.
  • מאתחלים את GKE Autopilot ומתקינים את ה-CRD של Agent Sandbox, את ההגדרות של האשכול ואת Sandbox Router.
  • פורסים את Sandbox Gateway, את Sandbox Claim Template ואת Sandbox WarmPool.
  • פורסים את ה-API ל-REST של ה-Backend, את סוכן העובד של ADK Judging ואת ממשק המשתמש של ה-Frontend ב-React.
  • אפשר להגדיר ניתוב חיצוני מאוזן עומסים ולגשת לפלטפורמה כדי להריץ תהליכי עבודה מאובטחים של שיפוט בארגז חול.

הדרישות

  • דפדפן אינטרנט כמו Chrome.
  • פרויקט ב-Google Cloud שהחיוב בו מופעל.

העלות של המשאבים שנוצרו ב-Codelab הזה צריכה להיות פחות מ-5 $בסך הכול.

2. הבעיה: הערכה מאובטחת של קוד לא מהימן

האקתונים הם אירועים מהירים שבהם המשתתפים יוצרים ושולחים פרויקטים – לרוב כולל קוד מקור – להערכה. בדיקה ידנית של הפריטים האלה דורשת זמן ומשאבים רבים. שימוש בסוכני AI כדי להפוך את מתן הציונים לאוטומטי הוא פתרון מבטיח, אבל הוא מעלה אתגר אבטחה משמעותי: איך מריצים בבטחה קוד שסופק על ידי המשתתפים, שיכול להיות מלא באגים, זדוני או עתיר משאבים?

הפעלת קוד לא מהימן ישירות בתשתית חושפת אתכם לסיכונים כמו:

  • החדרת קוד: סקריפטים זדוניים עלולים לנסות לגשת למידע אישי רגיש או לשנות אותו.
  • הסלמת הרשאות (privilege escalation): יכול להיות שהקוד ינסה לקבל גישה לא מורשית למערכות אחרות או למשאבי רשת.
  • ניצול לרעה של משאבים: קוד שנכתב בצורה לא טובה או מתקפות מניעת שירות (DoS) עלולים לצרוך כמות מוגזמת של מעבד (CPU), זיכרון או רוחב פס ברשת, ולהשפיע על פעולות אחרות.

כדי להפוך את השיפוט בהאקתון לאוטומטי באמצעות AI, אנחנו צריכים דרך להריץ את הקוד שנשלח בסביבה שמבודדת לחלוטין משאר המערכת שלנו ומפריטים אחרים שנשלחו.

3. הפתרון: ארגז חול לסוכנים ב-GKE

ארגז החול לסוכנים ב-GKE הוא תכונה שנועדה בדיוק למטרה הזו. הוא עוזר לנהל עומסי עבודה מבודדים, מבוססי-מצב ועם עותק יחיד ב-GKE, והוא מותאם לתרחישי שימוש כמו זמני ריצה של סוכני AI שבהם צריך להריץ קוד לא מהימן בצורה מאובטחת ויעילה.

היתרונות המרכזיים של ארגז החול של הסוכן:

  • בידוד ברמת ליבת מערכת ההפעלה: מספק בידוד חזק ברמת ליבת מערכת ההפעלה לקוד לא מהימן באמצעות טכנולוגיות כמו gVisor, ומונע מהקוד לגשת למערכת המארחת או למאגרי קונטיינרים אחרים.
  • הקצאת משאבים תוך פחות משנייה: הקצאת משאבים מהירה של סביבות ארגז חול (בדרך כלל תוך פחות משנייה), שהיא חיונית להערכת קוד לפי דרישה.
  • הרחבה מובנית בענן: שימוש ביכולות של Kubernetes ובתשתית המנוהלת של GKE.

באמצעות Agent Sandbox, אנחנו יכולים ליצור סביבות מבודדות לפי דרישה לכל פתרון שנשלח להאקתון. לאחר מכן, נציג ה-AI לבדיקה יכול להנחות את ארגז החול של הנציג להריץ בדיקות, לקמפל קוד או לבצע שלבי הערכה אחרים בארגז החול המאובטח הזה, בלי לסכן את השלמות של הפלטפורמה הכוללת. השיטה הזו מאפשרת להפוך את תהליך מתן הציונים בהאקתון לאוטומטי, בצורה יעילה, מאובטחת וניתנת להרחבה.

4. לפני שתתחיל

הפעלת Cloud Shell

כדי להתחיל להשתמש ב-Google Cloud Shell, שמוגדר מראש עם כלי שורת הפקודה הנדרשים למפתחים ולענן, לוחצים על הלחצן שלמטה.

הפעלת ממשקי ה-API

מריצים את הפקודה הבאה ב-Cloud Shell כדי להפעיל את כל ממשקי ה-API של Google Cloud שנדרשים להפעלת הפלטפורמה:

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

למה אנחנו מפעילים את ממשקי ה-API האלה: שירותי Google Cloud מושבתים כברירת מחדל כדי למנוע גישה וחיובים לא מורשים. אנחנו מפעילים את ממשקי ה-API הספציפיים האלה כדי להפעיל תזמור קונטיינרים (GKE), אחסון מאובטח של קונטיינרים (Artifact Registry), אריזת build ללא שרת (Cloud Build), תורים אמינים של הודעות (Pub/Sub), שירותי מודלים של AI‏ (Vertex AI), הגדרת פרויקטים (Cloud Resource Manager ו-IAM), ניתוח נתונים ללא שרת (BigQuery) וקישורי AI ברמת מסד הנתונים (BigQuery Connection).

5. הגדרת התשתית

בשלב הזה, תשכפלו את מאגר המקורות של הקוד ותריצו את סקריפט ההגדרה האוטומטי כדי לפרוס את ארכיטקטורת הענן של היעד ואת רכיבי האשכול הבסיסיים.

שכפול המאגר

משכפלים את המאגר שמכיל את כל שירותי האפליקציות, סקריפטים להגדרה והצהרות של מניפסט 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

הפעלת סקריפט פריסה

ההגדרה הבסיסית של משאבי הענן, מודלים של מסדי נתונים ומדיניות בסיסית של אשכול Kubernetes מתבצעת באופן אוטומטי על ידי סקריפט deploy.sh.

מריצים את הסקריפט:

./deploy.sh

פועלים לפי ההנחיות במעטפת האינטראקטיבית כדי לספק הגדרות כמו מזהה הפרויקט הפעיל ואזור היעד. הסקריפט יוצר באופן אוטומטי הגדרה מקומית של .env, קושר משאבים, מהדר תמונות של קונטיינרים ורושם תשתית בסיסית של GKE.

אלה פעולות היעד שהסקריפט מבצע:

1. הגדרת תצורת הסביבה

הסקריפט יוצר קובץ הגדרות .env לאחסון פרמטרים של משתנים בפרויקט, ב-GKE, ב-Pub/Sub וב-BigQuery. הוספת הקובץ הזה באופן דינמי מאכלסת את כל ההגדרות הבאות של מניפסט Kubernetes.

למה אנחנו מגדירים את קובץ הסביבה הזה: הקובץ .env מרכז את פרמטרי ההגדרה, כדי להבטיח שמניפסטים של GKE שאנחנו מפעילים באופן ידני בשלבים הבאים ישתמשו בהגדרות אזוריות, בשמות פרויקטים ובמשאבים זהים, תוך הפרדה מוחלטת בין הגדרות הסביבה לבין קוד המקור.

2. הגדרת פרויקט היעד ב-Google Cloud CLI

הסקריפט מוודא שהכלי gcloud, bq, kubectl ו-envsubst מותקנים, בודק את מצב האימות ונועל את יעדי ההגדרה הפעילים בפרויקט בענן הפעיל שלכם ב-Google Cloud.

למה אנחנו מכוונים לפרויקט הפעיל: הגדרת פרויקט היעד הפעיל מונעת מפקודות CLI להשפיע על פרויקטים אחרים בחשבון, ומבצעת בדיקות אימות לפני ההפעלה כדי לוודא שפקודות ההגדרה לא ייכשלו באמצע הפריסה בגלל פרטי כניסה לא תקינים.

3. הפעלת ממשקי API של Google Cloud

הסקריפט מבצע בדיקה אידמפוטנטית כדי לאמת ולהפעיל את ממשקי ה-API של שירות Google Cloud (GKE,‏ Artifact Registry,‏ Cloud Build,‏ Pub/Sub,‏ Vertex AI,‏ BigQuery ו-IAM).

למה אנחנו מפעילים ממשקי API של Google Cloud: צריך להפעיל שירותי ענן מנוהלים לפני שאפשר להגיע לנקודות הקצה שלהם או ליצור משאבים. הפעלתם בהתחלה מכינה את שער ה-API האזורי של GCP לטיפול בפקודות הבאות להקצאת משאבים.

4. הקצאת מאגר Docker ב-Artifact Registry

הסקריפט מקצה מאגר תגים של Docker בשם hackathon-judge-repo במיקום היעד שנבחר.

למה אנחנו יוצרים מאגר ב-Artifact Registry: כדי למשוך במהירות תמונות של אפליקציות, אשכולות GKE צריכים גישה מאובטחת למאגרי קונטיינרים פרטיים באותה רשת אזורית. ‫Artifact Registry מספק מארח פרטי ומאובטח לקטלוג, לסריקה ולאחסון של קובצי אימג' לקונטיינרים של Docker.

5. הקצאת אשכול GKE Autopilot

הסקריפט מספק אשכול Google Kubernetes Engine ‏ (GKE) במצב Autopilot בשם hackathon-judge-cluster.

למה אנחנו פורסים אשכול GKE Autopilot: GKE Autopilot מנהל באופן אוטומטי את הקצאת הצמתים, את שינוי הגודל, את ניטור תקינות ואת שדרוגי האבטחה של מערכת ההפעלה המארחת. הפלטפורמה מספקת קונטיינר ברמת ייצור לתיאום השירותים המתמשכים שלנו, ומתזמנת באופן דינמי ארגזי חול מאובטחים של עובדים לפי דרישה.

6. הגדרת נושאים ומינויים ב-Pub/Sub

הסקריפט מספק את נושאי ההודעות (judging-tasks ו-judging-results) יחד עם המינויים המתאימים ל-worker ול-API.

למה אנחנו פורסים נושאים ומינויים ב-Pub/Sub: בדיקת קוד שנשלח היא תהליך איטי שדורש הרבה משאבים. שימוש בארכיטקטורה של תור הודעות מפריד בין ממשק ה-API הסינכרוני שפונה למשתמשים לבין צמתי העובדים. הקצה העורפי של ה-API דוחף משימות לנושא judging-tasks, וסוכני העובדים מושכים משימות כשהן זמינות, וכך מונעים חסימה של ה-API ומספקים יכולות ניסיון חוזר אוטומטי.

7. הגדרה של מערכי נתונים, טבלאות וחיבורי AI ב-BigQuery

הסקריפט יוצר את מערך הנתונים hackathon_judge, מחיל סכימות מבניות של מסד נתונים SQL, טוען רשומות ראשוניות ומעניק את תפקידי ה-AI והאחסון הנדרשים לחשבון השירות של שירות החיבור BigQuery ML.

8. הפעלת בנייה של קונטיינרים באמצעות Cloud Build

הסקריפט מפעיל את ההגדרה של cloudbuild.yaml כדי לקמפל את ממשק המשתמש של React, את שרת Go REST, את העובד של Python ADK ואת ארגז החול של FastAPI, לארוז אותם בקובצי אימג' מבודדים של קונטיינר שתויגו באמצעות ה-SHA של ה-commit ב-Git של המאגר הפעיל, ולשמור אותם ב-Artifact Registry.

9. רישום של הגדרות משאבים בהתאמה אישית (CRD) של ארגז החול של הסוכן

הסקריפט מוריד ומירשם את ההגדרות העדכניות של משאבים מותאמים אישית (manifest.yaml ו-extensions.yaml) של ארגז החול לסוכנים של Kubernetes-sigs, כדי להרחיב את היכולות הבסיסיות של GKE.

למה אנחנו מתקינים את התשתית של ארגז החול של הסוכן: באשכולות Kubernetes רגילים אין תמיכה בהקצאת ארגזי חול מוגנים לפי דרישה. רישום של CRD של ארגז החול לסוכנים מרחיב את רמת הבקרה של GKE, ומאפשר ל-Kubernetes לתזמר באופן מקורי מיקרו-קונטיינרים מאובטחים בתוך ארגז חול באמצעות משאבים בהתאמה אישית (כמו SandboxTemplates ו-SandboxClaims).

10. הגדרה של מרחבי שמות, חשבונות שירות ו-Workload Identity

הסקריפט מקצה את מרחב השמות hackathon-judge, רושם חשבונות שירות של Kubernetes‏ (KSA) ומגדיר מיפוי של Workload Identity כדי להעניק ל-Pods של GKE הרשאות יעד ב-Google Cloud.

11. פריסת נתב ארגז החול

הסקריפט מחיל את k8s/sandbox_router.yaml המניפסט, מתחיל את הפריסה של נתב ארגז החול והשירות וממתין עד שהם יגיעו לסטטוס תקין.

למה אנחנו פורסים את נתב ארגז החול: נתב ארגז החול הוא שער מרכזי של מישור הבקרה הפנימי. הוא חושף API פשוט שהסוכן של העובד ב-ADK קורא כדי לתבוע, לגשת או לשחרר ארגזי חול מאובטחים, לנהל מיפויי ניתוב ולהפריד את הקצאת הפודים ברמת האשכול מהלוגיקה של האפליקציה.

6. הגדרת שער ארגז החול של הסוכן, טענות ו-WarmPool

בשלב הזה, תגדירו באופן ידני את שער הרשת של ארגז החול המיוחד, תרשמו את תבנית התביעה של ארגז החול ותפרסו את מאגר החימום של ארגז החול כדי להפעיל ארגז חול עם זמן טעינה קצר במיוחד.

משתני סביבה של המקור

לפני שמחילים תבניות שדורשות משתני סביבה, צריך להפעיל את הסקריפט setup-env.sh כדי לנתח ולייצא את כל המשתנים הנדרשים למעטפת:

source ./setup-env.sh

החלת שער ארגז חול

פריסת השער שהוגדר במיוחד לניתוב תנועה לארגז החול:

kubectl apply -f k8s/sandbox-gateway.yaml

למה אנחנו פורסים את Sandbox Gateway:‏ Sandbox Gateway פועל כבקר כניסה מאובטח עם ביצועים גבוהים, שמוקדש רק לניתוב של ארגז החול. היא מבודדת את רשת ארגז החול ומספקת יעד מקומי מאובטח שמאפשר לסוכני העובדים לתקשר עם ארגזי חול מוצהרים בלי לחשוף נקודות קצה חיצוניות.

שימוש בתבנית של בקשת גישה לארגז חול

משתמשים ב-envsubst כדי לאכלס את הגדרת תבנית הארגז עם משתני הסביבה הפעילים, ומחילים אותה:

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

למה אנחנו פורסים את תבנית ההצהרה על ארגז החול: תבנית ההצהרה על ארגז החול משמשת כתוכנית ההגדרה שמגדירה את הסביבה. הוא מציין את קובץ האימג' של הקונטיינר להרצה (שמגיע עם כלי פיתוח), פרמטרים של הסביבה (מזהה הפרויקט ב-GCP), יציאות ומגבלות משאבים (יעדי CPU/זיכרון). הוא מגדיר את GKE להפעיל את מופעי הקונטיינר האלה באמצעות gVisor (סביבת זמן ריצה של gVisor), כדי להבטיח שקוד של משתתפים לא מהימנים יפעל בשכבה נוספת של בידוד וירטואליזציה של ליבת המערכת.

החלת Sandbox WarmPool

החלת Sandbox WarmPool כדי לבצע אתחול מראש של ארגזי חול פעילים:

kubectl apply -f k8s/sandbox-warmpool.yaml

מוודאים שהמכונות הווירטואליות במצב המתנה במאגר החם הופעלו בהצלחה:

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

למה אנחנו פורסים את Sandbox WarmPool: הקצאת משאבים, תזמון, שליפת תמונות והפעלה של Pods של קונטיינרים חדשים על פי דרישה יוצרים תקורה משמעותית של הפעלה (זמני הפעלה במצב התחלתי (cold start) של 30 שניות ומעלה). ב-Sandbox WarmPool יש מאגר המתנה של תרמילי ארגז חול פעילים שחוממו מראש (5 העתקים כברירת מחדל). כשסוכן העובד מבקש סביבת הערכה, נתב ארגז החול מקצה מיד פוד שמופעל מראש, וכך מצמצם את העיכובים בהפעלה למהירויות של פחות משנייה.

7. פריסת רכיבי אפליקציות

תשתית ארגז החול המאובטחת פעילה באופן מלא, ועכשיו אפשר לפרוס את ה-API המרכזי של ה-Backend, את סוכן העובד, את ממשק האינטרנט של React ואת מיפוי שער הכניסה.

פריסת קצה עורפי

פורסים את ה-API בארכיטקטורת REST של כלי התזמור:

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

פריסת הסוכן

פריסת סוכן ADK לשיפוט עובדים:

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

פריסת הקצה הקדמי

פורסים את ממשק המשתמש האינטראקטיבי באינטרנט:

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

הגדרת שער וניתוב חיצוניים

פריסת שער ראשי ומיפוי של נתיבי HTTP של תנועת לקוחות חיצונית:

kubectl apply -f k8s/gateway.yaml

למה אנחנו פורסים את שער הכניסה החיצוני: השער החיצוני חושף את השירותים שלנו באמצעות Kubernetes Gateway API. הוא מקצה כתובת IP ציבורית עם איזון עומסים וממפה מסלולים על סמך כללי נתיב – הוא מפנה בקשות API בנתיב /api/* אל קצה העורף של Go וממפה את כל תנועת האינטרנט של הלקוח (/) אל קצה החזית של React, וכך מאבטח את הגישה לאשכול הציבורי.

אימות השקות

חוסמים את ההפעלה של המעטפת וממתינים עד שכל שלושת פריסות שירות הליבה יגיעו לסטטוס תקין של מוכנות להשקה:

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. אימות ושימוש באפליקציה

גישה לממשק המשתמש

מאחזרים את כתובת ה-IP הציבורית החיצונית של שער מאזן העומסים הראשי שהוקצה לאחרונה:

כדי לצפות בסטטוס הקצאת המשאבים בזמן אמת, מריצים את הפקודה עם הדגל watch ‏ (-w) ומחכים עד שכתובת IP ציבורית מאוכלסת בשדה ADDRESS:

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

אם ההקצאה בוצעה בהצלחה, הפלט אמור להיראות כך:

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

אחרי שרואים כתובת IP ציבורית תקינה בעמודה ADDRESS והסטטוס PROGRAMMED הוא True, לוחצים על Ctrl+C כדי להפסיק את הצפייה.

למה אנחנו מקבלים את סטטוס השער: Gateway API מטפל בתעבורה נכנסת ציבורית. בדיקת הסטטוס של השער מחזירה את כתובת ה-IP החיצונית הציבורית שמאוזנת על ידי מאזן העומסים החיצוני הגלובלי של Google Cloud שהוקצתה לאשכול שלנו, שמייצגת את הכתובת הציבורית של הפלטפורמה שלנו.

פותחים את כתובת ה-IP הציבורית שהוקצתה בדפדפן כדי לטעון את מרכז הבקרה של השופטים בהאקתון.

שליחת משימות

  • משתמשים בממשק המשתמש של הקצה הקדמי כדי לנווט אל לוח הבקרה ולבחור את ההאקתון.

מרכז הבקרה

  • בכל אחד מהפרויקטים, אפשר ללחוץ על Run Agent כדי שהסוכן יתחיל לשפוט את הפרויקט כולו לפי קריטריון ההערכה.

פרויקטים

צפייה בסרטון Sandbox Kickoff

כדי לראות פוד ארגז חול שמוקצה ומסופק באופן דינמי לשיפוט הביצוע, עוקבים אחרי הפודים הפעילים במרחב השמות hackathon-judge:

kubectl get pods -n hackathon-judge -w

כדי לראות את הלוגיקה של ההערכה באמצעות ADK, שלב אחר שלב, אפשר לבדוק את הלוגים של ה-pod של סוכן העובד:

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

למה אנחנו בודקים את יומני הסוכן: בדיקת יומני הסוכן של העובד מציגה את השלבים הפנימיים המפורטים של צינור ההערכה בזמן אמת. אתם יכולים לעקוב אחרי סוכן ADK שמביא את המשימה, מבקש מארז ארגז חול, מבצע יעדי קומפילציה, מנתח דוחות באמצעות Gemini ומפרסם כרטיסי מידע.

9. (אופציונלי) איך זה עובד

ארכיטקטורת ארגז החול של הסוכן

פונקציות ה-AI של BigQuery מצוינות להערכת הצעות מבוססות-טקסט וטענות בקובץ README, אבל כדי לשפוט פרויקט הנדסי צריך לקמפל קוד, להתקין ספריות של צד שלישי ולהריץ חבילות בדיקה אמיתיות.

הפעלת קוד משתמש גולמי יוצרת סיכוני אבטחה משמעותיים, כולל פריצה למארח, פריצה למאגרים וגישה לא מורשית למשאבים. המסגרת GKE Agent Sandbox מצמצמת את הסיכונים האלה באמצעות תזמור של עומסי עבודה מבודדים בארגז חול, תוך שימוש בווירטואליזציה של gVisor (runsc).

זרימת האינטראקציה עם המערכת

התרשים הבא ממפה כיצד האלמנטים השונים במערכת מבוססת-האירועים שלנו מתקשרים במהלך ביצוע שיפוט מאובטח בסביבת ארגז חול:

איך כלי ורכיבי המעורבות פועלים יחד

  • ממשק משתמש של Front-end ב-React: חושף ממשק אינטראקטיבי שבו משתמשים מגדירים מודלים של קריטריונים, רושמים צוותים, שולחים כתובות URL של פרויקטים ומעיינים בגיליונות סופיים של ציוני דירוג, כולל אי התאמות מלאות בקבצים ותגובות הנדסיות.
  • ‫Go REST Backend API: מנהל נקודות קצה גלובליות של API. הוא שומר את הגדרות הפרויקט ב-BigQuery ושולח משימות שיפוט ל-Pub/Sub כדי להפריד בין צינורות להרצת חישובים כבדים.
  • ‫Google Pub/Sub: ברוקר מבוסס-הודעות שמחזיק בבטחה הודעות של משימות בתור, ומנהל תקשורת אסינכרונית בין ה-API לבין מופעים פעילים של עובדים.
  • תהליך עבודה של Python ADK (סוכן Supervisor): תהליך עבודה ברקע ששולף משימות מ-Pub/Sub. הוא משתמש בערכה לפיתוח סוכנים (ADK) של Google כדי להפעיל סוכן מפקח ברמה גבוהה, שמקבל הוראה לתזמן את ההערכה. המפקח מפעיל את הכלי הראשי שלו, evaluate_repository, כדי להעביר את הבדיקה של פקודות גולמיות מורכבות.
  • ‫נתב ושער Sandbox (מישור הבקרה של GKE): שער בקרה פנימי שרושם הגדרות סטנדרטיות של משאבים מותאמים אישית של Sandbox ‏ (SandboxClaims, SandboxTemplates). הוא מתאם בין רשתות GKE כדי להקצות ולשמור על Podים, ומחזיר זרמי חיבור ללקוחות של ה-workerים.
  • ‫Sandbox WarmPool: כדי למנוע זמני הפעלה ארוכים של קונטיינרים ב-GKE (הפעלות במצב התחלתי של 30 שניות ומעלה), ה-WarmPool שומר על פודים פעילים במצב המתנה. כשמבצעים תביעה על ארגז חול, הנתב ממפה אותו מיד תוך פחות משנייה, ואז מתזמן את המיחזור שלו אחרי השחרור.
  • בידוד באמצעות gVisor‏ (runsc): ליבה וירטואלית של סביבת משתמש שפועלת כגבול מאובטח של ארגז חול. היא מיירטת קריאות למערכת ממרחב המאגר לליבות של צומתי GKE, כדי להבטיח שפקודות גולמיות מסוכנות (כמו סקריפטים של המערכת או הגדרות של חבילות) יפעלו בבידוד וירטואלי מוחלט.
  • FastAPI Sandbox Runtime: שרת API קל משקל בשפת Python שפועל בתוך קונטיינר ארגז החול. הוא חושף נקודות קצה מאובטחות (/execute, /upload, /download) שמאפשרות לכלי עובדים חיצוניים לבצע מניפולציות בקבצים ולהפעיל משימות של מעטפת.
  • ‫Gemini CLI (@google/gemini-cli): סקריפט של סוכן אוטונומי שמותקן בתוך ארגז החול. כשמפעילים אותו באמצעות דגל זמן הריצה של סביבת הפיתוח (--yolo), הוא משתמש בגיליון הוראות קפדני למתן ציונים (prompt.md) ובהגדרת קריטריונים (criteria.md) כדי:
    • לנתח באופן דינמי את ההיררכיה של בסיס הקוד (באמצעות כלים כמו tree או ripgrep).
    • התקנה אוטומטית של הדרישות (באמצעות פקודות כמו npm install, ‏ pip install, ‏ go build).
    • מריצים בדיקות פיתוח אמיתיות (כמו npm test או pytest) כדי לאמת את הפונקציונליות.
    • הפעלת מודלים של Vertex AI (באמצעות פרטי הכניסה של קישור Workload Identity של הקונטיינר) כדי להעריך את הלוגיקה של הקובץ, לבצע בדיקה צולבת של הטענות מול קובץ ה-README, לזהות תכונות רפאים, לתעד בעיות באיכות ולכתוב דוח מובנה של כרטיס ניקוד אל evaluation.json.
  • סביבות פיתוח רגילות: חבילה של node,‏ npm,‏ yarn,‏ pnpm,‏ python,‏ pip,‏ uv,‏ go,‏ gh,‏ git,‏ tree,‏ ripgrep ו-playwright בקובץ אימג' של קונטיינר של ארגז החול, שנותנת לסוכן המשנה האוטונומי סביבת עבודה מלאה לבדיקה.

10. הסרת המשאבים

כדי להימנע מחיובים שוטפים בחשבון Google Cloud, מוחקים את המשאבים שנוצרו במהלך ה-codelab הזה.

./destroy.sh

למה אנחנו מנקים משאבים: החיוב ב-Google Cloud מבוסס על מודל של ניצול משאבים. משאבים פעילים כמו אשכולות GKE Autopilot, מאזני עומסים ברשת ודיסקים קשיחים גוררים חיובים שוטפים גם כשהם לא פעילים. הפעלת השלב הזה מוחקת את מרחב השמות של האשכול כדי לנקות את אובייקטי Kubernetes, ומוחקת את המארח של אשכול GKE Autopilot עצמו כדי להפסיק באופן מיידי את כל חיובים הבסיסיים.

11. מזל טוב

מעולה! פרסתם בהצלחה את אפליקציית השופט בתחרות ההאקתון עם Agent Sandbox ב-GKE.

הטמעתם פלטפורמת AI מאובטחת ומודרנית שמבוססת על אירועים, שיכולה לבדוק ולהעריך בסיס קוד שנשלח ממקורות לא מהימנים במסגרת מגבלות אבטחה מבודדות בקונטיינרים.

מה למדתם

  • תשתית GKE: איך להקצות GKE Autopilot ושירותי Google Cloud תומכים כמו Pub/Sub ו-BigQuery.
  • הגדרת ארגז חול של סוכן: איך מגדירים הגדרות של משאבים מותאמים אישית, SandboxTemplates,‏ SandboxClaims ו-Sandbox WarmPools עם ביצועים גבוהים.
  • פריסת מיקרו-שירותים: איך להגדיר קישורים של Workload Identity ולפרוס ארכיטקטורה של מיקרו-שירותים מרובי רכיבים (Frontend React,‏ REST Go,‏ Worker ADK Agent וארגז חול מבודד).
  • ארגז חול מאובטח: איך משתמשים בקונטיינרים וירטואליים של gVisor כדי להריץ בצורה מאובטחת פקודות של צד שלישי לא מהימן בצמתים של GKE.

השלבים הבאים

מסמכי עזר