מידע על Agent Sandbox ב-GKE

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

‫Agent Sandbox הוא פרויקט קוד פתוח במסגרת Kubernetes SIG Apps. כדי להשתמש ב-Agent Sandbox ב-GKE, צריך להתקין את הבקר של Agent Sandbox באשכול. אתם אחראים לשדרוג הבקר. איך מתקינים את Agent Sandbox ב-GKE

במאמר הזה מוסבר באופן כללי על Agent Sandbox ב-GKE.

בחירה בין ארכיטקטורות מבוססות-Pod לארכיטקטורות מבוססות-שחקן

ב-GKE יש שתי ארכיטקטורות לתזמור של עומסי עבודה של סוכני AI:

  • ‫Agent Substrate ב-GKE (מבוסס-שחקן): משתמשים בארכיטקטורה הזו לרוב עומסי העבודה של סוכני AI, במיוחד סוכנים עם שמירת מצב (stateful) שמושעים ומופעלים מחדש לעיתים קרובות. סוכנים פעילים חולקים מאגר של Pods חמים במקום להחזיק Pod ייעודי לכל סוכן, כך שאפשר להריץ יותר סוכנים על פחות צמתים. ‫Agent Substrate ב-GKE מספק השעיה וחידוש אוטומטיים של עומסי עבודה לא פעילים. המערכת שומרת את הזיכרון והקבצים של כל סוכן לא פעיל באחסון, ומשחזרת את הסוכן תוך פחות משנייה. לעומת זאת, ב-Agent Sandbox ב-GKE צריך לבצע תמונת מצב של Pod באופן ידני, וצריך לפתח קוד אפליקציה כדי לזהות חוסר פעילות ולשמור את ההתקדמות של הסוכן. כדי להשתמש ב-Agent Substrate ב-GKE, צריך אשכול GKE Standard. מידע נוסף זמין במאמר מידע על Agent Substrate ב-GKE.
  • ‫Agent Sandbox ב-GKE (מבוסס-Pod): השתמשו בארכיטקטורה הזו כשכל סוכן צריך Pod ייעודי של Kubernetes באשכול GKE Autopilot או Standard. בחרו באפשרות הזו לסוכנים או לעומסי עבודה שפועלים באופן רציף ודורשים:
    • ממשקי API דקלרטיביים של Kubernetes, כמו המשאבים המותאמים אישית Sandbox ו-SandboxClaim
    • סכימת PodSpec המלאה של Kubernetes, כולל קונטיינרים בהתאמה אישית של sidecar ו-init
    • גישה ישירה למאיצי חומרה, כמו מעבדי GPU או TPU
    • אשכולות GKE Autopilot

למה כדאי להשתמש ב-Agent Sandbox ב-GKE

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

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

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

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

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

תרחישים נפוצים לדוגמה לשימוש ב-Agent Sandbox ב-GKE

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

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

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

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

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

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

מודל תביעת הבעלות

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

מודל התלונה משתמש במשאבים המותאמים אישית SandboxClaim,‏ SandboxWarmPool ו-SandboxTemplate, והוא פועל באופן הבא:

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

בריכות חמות

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

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

בידוד הרשת

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

הבקר לא יוצר משאב NetworkPolicy למשאב Sandbox שאתם יוצרים ישירות. כדי להגביל את הגישה לרשת לארגזי החול האלה, צריך ליצור משאב NetworkPolicy משלכם.

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

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

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

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

  • גרסת האשכול: אפשר להריץ את Agent Sandbox ב-GKE בכל גרסה נתמכת של GKE. כדי להשתמש בתמונות מצב של Pod, האשכול צריך להריץ את GKE בגרסה 1.35.3-gke.1234000 ואילך.
  • דרישות תשתית: צריך להתקין ולהגדיר את הבקר של Agent Sandbox באשכול. כדי להשתמש ב-Agent Sandbox ב-GKE לא צריך סוג מכונה ספציפי. לדוגמה, במדריך ההתקנה נעשה שימוש בצמתים של e2-standard-2. עם זאת, תמונות מצב של Pod לא תומכות בסוגי מכונות E2, אז אם אתם מתכננים להשתמש בתמונות מצב של Pod, השתמשו בסדרת מכונות אחרת, כמו N2.
  • סביבות הרצה מבודדות: Agent Sandbox ב-GKE תומך ב-gVisor וב-microVMs כסביבות הרצה מבודדות. כדי להשתמש בתמונות מצב של Pod צריך את gVisor, והן לא פועלות עם מכונות וירטואליות זעירות. אם לא תציינו סביבת זמן ריצה לארגז החול, ארגזי החול יפעלו ללא בידוד ליבה (kernel). אנחנו לא ממליצים על כך לקוד לא מהימן.
  • זמינות של תכונות בסיסיות: יכול להיות שתכונות בסיסיות מסוימות, כמו תמונות מצב של Pod ב-GKE, יהיו בגרסת טרום-השקה (Preview) או יהיו זמינות רק באזורים מסוימים.

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