מידע על Agent Sandbox ב-GKE

ארגז החול לסוכנים ב-Google Kubernetes Engine ‏ (GKE) עוזר לנהל עומסי עבודה מבודדים, עם שמירת מצב ועם רפליקה אחת. היא מותאמת לתרחישי שימוש כמו זמני ריצה של סוכני AI, שבהם צריך להריץ קוד לא מהימן שנוצר על ידי LLM בסביבה מאובטחת עם ביצועים טובים.

התוסף Agent Sandbox ב-GKE מבוסס על פרויקט הקוד הפתוח של בקר Agent Sandbox ופועל בהתאם למחזורי השחרור שלו. כתוסף מנוהל של GKE, ‏ Google מנהלת את מחזור החיים המלא של בקר התוסף, כולל שדרוגים אוטומטיים ותיקוני אבטחה.

במאמר הזה מוסבר מהו ארגז החול לסוכנים ב-GKE.

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

‫Agent Sandbox ב-GKE מיועד לעומסי עבודה של סוכנים שדורשים רמה גבוהה של סקיילינג, יכולת הרחבה ואבטחה. היתרונות העיקריים של מודעות למכירת רכב:

  • בידוד ברמת הליבה (kernel): בידוד חזק ברמת הליבה לקוד לא מהימן שנוצר על ידי LLM. ארגז החול של הסוכן ב-GKE פועל גם עם Kata Containers בקוד פתוח. מדריך לשימוש ב-Kata Containers בקוד פתוח עם Agent Sandbox ב-GKE זמין במאמר הפעלת Kata Containers ב-GKE.

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

  • הרחבה מובנית בענן: שימוש בעוצמה של פרדיגמת Kubernetes ובתשתית המנוהלת של GKE.

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

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

כדאי להשתמש ב-Agent Sandbox ב-GKE לעומסי עבודה שדורשים בידוד, שמירה וזהות יציבה. תרחישים לדוגמה:

  • זמני ריצה של סוכני AI: הרצת קוד לא מהימן בצורה בטוחה בסביבה מבודדת באמצעות זמני ריצה שמתמקדים באבטחה, כמו gVisor.
  • סביבות פיתוח: מספקות למפתחים סביבות קידוד קבועות ומבודדות מבוססות-ענן.
  • Notebooks וכלי מחקר: אירוח סשנים של קונטיינר יחיד לכלים אינטראקטיביים כמו Jupyter Notebooks.
  • שירותים של Pod יחיד עם שמירת מצב: הפעלת אפליקציות שזקוקות לזהות ולאחסון יציבים בלי המורכבות של StatefulSet.
  • ניהול סביבה פרוגרמטי: אתם יכולים להשתמש בערכות ה-SDK של ספריית הלקוח שסופקו, כמו Agent Sandbox Python SDK, כדי לבקש ולנהל ארגזי חול ישירות מהלוגיקה של האפליקציה בלי לנהל את Kubernetes YAML.

איך פועל Agent Sandbox ב-GKE

ארגז החול לסוכנים ב-GKE משתמש בבקר בהתאמה אישית ובכמה הגדרות של משאבים בהתאמה אישית (CRD) ב-Kubernetes כדי לנהל את מחזור החיים של סביבות ארגז החול.

ארכיטקטורת ליבה

  • ‫Sandbox CRD: המשאב הראשי שמייצג Pod יחיד עם שמירת מצב. הוא מנהל שמות מארחים יציבים, זהות רשת ואחסון מתמיד.
  • נתב Sandbox: רכיב שמספק נקודת קצה יציבה ומעביר את התנועה לפודים המתאימים של Sandbox, תוך הפשטה של מורכבות הרשת הבסיסית.
  • שילוב עם תמונות מצב של Pod: Agent Sandbox ב-GKE משולב עם התכונה GKE Pod snapshots כדי לאפשר השהיה והפעלה מחדש של עומסי עבודה על ידי שמירה ושחזור של המצב המלא של קונטיינר.

מודל התביעה

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

מודל התביעה מנוהל באמצעות ה-CRD‏ SandboxClaim ו-SandboxTemplate, והוא פועל באופן הבא:

  1. משתמשים או אפליקציות מבקשים ארגז חול על ידי יצירת SandboxClaim שמפנה אל SandboxTemplate.
  2. הבקר מטפל במיפוי של הטענה למופע בפועל של Sandbox, ומציע ניהול גמיש של הקצה העורפי. כך המערכת יכולה לעשות שימוש חוזר בארגזי חול קיימים או להקצות אותם ממאגר.

Warm Pools

התכונה Warm Pool נועדה לצמצם את זמן האחזור של תהליך ההפעלה, וזה קריטי בתרחישים של סוכני AI אינטראקטיביים. התכונה הזו מאפשרת לארגז החול לסוכנים ב-GKE לספק סביבות הרצה בפחות משנייה, מהר משמעותית מתזמון רגיל של Pod. התכונה מנוהלת באמצעות ה-CRD‏ SandboxWarmPool, והיא פועלת באופן הבא:

  1. SandboxWarmPool שומר על קבוצה של מכונות Pod שחוממו מראש במצב מוכן.
  2. כשנוצר SandboxClaim, הבקר מקצה באופן מיידי Pod מהמאגר במקום לחכות ש-Pod חדש ישלוף קובצי אימג' ויתחיל מאפס.
  3. כשמשלבים אותם עם תמונות מצב של Pod, מאגרי חום מספקים יכולות מהירות של הפעלה מיידית על ידי שחזור של Pod ממצב שהוגדר מראש.

בידוד רשת

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

גישה פרוגרמטית באמצעות ערכות SDK

מהנדסי AI יכולים להשתמש במשאבים של ארגז החול לסוכנים ב-GKE באופן פרוגרמטי באמצעות ספריות הלקוח שסופקו. לדוגמה, Python SDK מספק ממשק ברמה גבוהה שמבצע הפשטה של ההגדרות הבסיסיות של SandboxClaim ו-SandboxTemplate. כך אתם יכולים ליצור סביבות מבודדות ולקיים איתן אינטראקציה ישירות מסביבות פיתוח של סוכנים שמבוססות על Python, כמו LangChain או Vertex AI Agentic SDK.

מגבלות ודרישות

אלו הדרישות והמגבלות של Agent Sandbox ב-GKE:

  • גרסת האשכול: נדרשת גרסה ‎1.35.2-gke.1269000 ואילך של GKE לתמיכה מלאה בתכונה (כולל תמונות מצב).
  • דרישות תשתית: מותאם לתצורות ספציפיות של צמתים (למשל סוגי מכונות N2) ודורש שרכיב Agent Sandbox Controller יהיה מותקן ומוגדר באשכול.
  • סביבות הרצה מבודדות: למרות שהיא תומכת בכמה סביבות הרצה, היא מיועדת בעיקר לשימוש עם סביבות הרצה מאובטחות כמו gVisor.
  • זמינות של תכונות בסיסיות: יכול להיות שתכונות בסיסיות מסוימות, כמו תמונות מצב של GKE Pod, יהיו בגרסת טרום-השקה או שיהיו זמינות באזורים ספציפיים.

המאמרים הבאים