מידע על Agent Substrate ב-GKE

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

‫Agent Substrate ב-GKE פותר את הבעיה הזו בכך שהוא מאפשר לאפליקציה להשעות סוכנים לא פעילים. כשהאפליקציה משעה סוכן, המערכת יוצרת תמונת מצב של הזיכרון הפעיל (RAM) ושל הקבצים המקומיים של הסוכן. כשהסוכן המושעה צריך לפעול שוב, המערכת משחזרת את מצב הסוכן בארגז חול (sandbox) זמין תוך פחות משנייה.

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

בפריסות רגילות של Kubernetes (כולל Agent Sandbox ב-GKE), כל עומס עבודה של סוכן משויך ל-Pod ייעודי. למרות ש-Kubernetes הוא מאוד סקלאבילי, הוא מוגבל על ידי קצב התזמון וזמן האחזור של הפעלת Pods. בנוסף, Kubernetes לא תומך במצב שינה של Pods, ואם מיליוני סוכנים לא פעילים יישארו באשכול, מגבלות ה-Pods וזיכרון מישור הבקרה ינוצלו עד תום. כדי להימנע מתשלום על משאבי מחשוב לא פעילים, צריך להשבית את ה-Pods ולנהל את מצב הסוכן באחסון חיצוני. ‫Agent Substrate ב-GKE פותר את מגבלות ההתאמה לעומס (scaling) האלה על ידי הפרדת מצב הסוכן מה-Pods הבסיסיים: הוא שומר מיליוני תמונות מצב מושהות של סוכנים באחסון ומשחזר אותן על פי דרישה למאגר משותף של עובדים חמים.

‫Agent Substrate ב-GKE היא מערכת בקוד פתוח שפורסים ישירות באשכולות GKE Standard. הפרויקט העיקרי מפותח במאגר Agent Substrate בקוד פתוח, אבל Google מספקת ללקוחות Google Cloud שעומדים בדרישות כלי פריסה וסקריפטים שמותאמים ל-GKE במאגר substrate-gke.

היתרונות של Agent Substrate ב-GKE

אתם יכולים להשתמש ב-Agent Substrate ב-GKE כדי להשיג את המטרות הבאות:

  • הרצת קוד לא מהימן בצורה בטוחה: Agent Substrate ב-GKE אוכף בידוד של הליבה ושל הרשת, כדי שתוכלו להריץ קוד שנוצר על ידי AI בלי לסכן את התשתית הרחבה יותר.
  • יצירת סוכנים עם זיכרון מצב (stateful) שפועלים לאורך זמן: זיכרון העבודה והקבצים של הסוכן נשמרים בין הסשנים. הסוכן ממשיך מהנקודה המדויקת שבה הוא הושהה.
  • תגובה לבקשות בזמן אמת: כשבקשה חדשה מפעילה סוכן מושהה, המערכת משחזרת את מצב הסוכן תוך שבריר שנייה.
  • הפחתת עלויות המחשוב: אפשר להריץ יותר סוכנים על פחות מכונות על ידי שיתוף מאגר של ארגזי חול של Worker בין כל הסוכנים. סוכנים לא פעילים מושעים ולא משתמשים במעבד ובזיכרון, ולכן אתם משלמים על המחשוב רק כשהסוכנים מעבדים משימות באופן פעיל.

תרחישים לדוגמה

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

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

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

‫Agent Substrate ב-GKE מבוסס על Kubernetes, אבל לא צריך להבין ב-Kubernetes כדי להשתמש בו. אלה המושגים העיקריים של Agent Substrate ב-GKE:

  • גורם: מופע פעיל יחיד של סוכן.
  • ‫ActorTemplate: תוכנית הגדרה (שמגדירה קובצי אימג' של קונטיינרים, משתני סביבה ומשאבי מחשוב) שמשמשת ליצירת מופעים של Actors.
  • Worker: ארגז חול (sandbox) שבו פועל Actor פעיל.
  • ‫WorkerPool: קבוצה של Workers שהופעלו מראש ונמצאים במצב המתנה, מוכנים לקבל Actor.

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

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

  1. ניתוב: כל בקשת API נכנסת מהאפליקציה מציינת את ה-Actor שאליו היא מיועדת. לדוגמה, כשמשתמש מקליד הנחיה חדשה בממשק צ'אט, האפליקציה שולחת בקשה שמיועדת ל-Actor הספציפי שמנהל את הסשן של המשתמש.
  2. המשך: אם הבקשה היא ל-Actor מושעה, המערכת תובעת Worker חם מ-WorkerPool ומשחזרת את קובץ ה-snapshot של ה-Actor ב-Worker הזה.
  3. ביצוע: המערכת מנתבת את הבקשה ל-Worker החדש שפעיל, וה-Actor מעבד את המשימה.
  4. השעיה: כשהאפליקציה משעה Actor לא פעיל, המערכת יוצרת תמונת מצב חדשה של הזיכרון והקבצים של ה-Actor, שומרת את תמונת המצב באחסון ומשחררת את ה-Worker הריק בחזרה למאגר.

בידוד של עומסי עבודה ו-GKE Sandbox

‫Agent Substrate ב-GKE משתמש ב-gVisor או ב-Cloud Hypervisor כדי להריץ כל עומס עבודה בארגז חול (sandbox) שמבודד את קוד האפליקציה מליבת המארח. ההתקנה של Agent Substrate ב-GKE כוללת סביבת זמן ריצה משלה של gVisor ל-Workers. אל תפעילו את GKE Sandbox במאגרי הצמתים שבהם פועל Agent Substrate ב-GKE, כי Agent Substrate ב-GKE לא יכול לפעול בצמתים האלה. אתם עדיין יכולים להשתמש ב-GKE Sandbox לעומסי עבודה אחרים, כולל Agent Sandbox ב-GKE.

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

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

  • מצב, גרסה וערוץ הפצה של האשכול: Agent Substrate ב-GKE תומך באשכולות GKE Standard שמישור הבקרה ומאגרי הצמתים שלהם פועלים בגרסה 1.37 ואילך. אי אפשר להשתמש באשכולות Autopilot ובגרסאות שקודמות ל-1.37. בגרסה 1.37 ואילך, GKE מציג את ממשקי ה-API של Kubernetes‏ podcertificaterequests ו-clustertrustbundles ומאפשר לצמתים לטעון אישורי Pod וחבילות אמון ל-Pods, כך שלא צריך להפעיל את גרסאות הבטא של ממשקי ה-API האלה בעצמכם. עם זאת, תוכנית ההתקנה מפעילה את גרסאות הבטא בכל אשכול שהיא יוצרת או מגדירה. ערוץ ההפצה המורחב לא תומך בממשקי API בגרסת בטא שמופעלים באופן מפורש, ולכן אי אפשר להשתמש בכלי ההתקנה עם אשכולות שרשומים לערוץ ההפצה המורחב.

  • איחוד זהויות של עומסי עבודה ל-GKE: באשכולות GKE צריך להפעיל את איחוד הזהויות של עומסי עבודה ל-GKE. ‫Agent Substrate ב-GKE משתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לאמת את ממשקי ה-API של Google Cloud , כמו Cloud Storage לשמירת קובצי Snapshot של סוכנים. כדי לשמור ולשחזר קובצי snapshot, המערכת משתמשת בחשבון שירות ייעודי בשם ate-snapshot-transfer. פרטי הכניסה לכל פעולת שמירה או שחזור יכולים לגשת רק לתמונות המצב של Actor אחד. לכן, אתם לא צריכים לתת לצומתי GKE גישה לקטגוריית קובצי ה-snapshot. מנהל ההתקנה יוצר את חשבון השירות ate-snapshot-transfer ונותן לו גישה לקטגוריית קובצי ה-snapshot. אם אתם מגדירים את ההרשאות בעצמכם, אתם צריכים להקצות את תפקידי ה-IAM הבאים:

    • בקטגוריית הסנאפשוט, מקצים לחשבון השירות ate-snapshot-transfer ולחשבון השירות של Kubernetes‏ ate-api-server את התפקידים "אדמין של אובייקטים באחסון" (roles/storage.objectAdmin) ו"צפייה בקטגוריות אחסון" (roles/storage.bucketViewer).
    • בחשבון השירות ate-snapshot-transfer, מקצים לחשבון השירות ate-api-server ב-Kubernetes את התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator). חשבון השירות ate-api-server מתחזה לחשבון השירות ate-snapshot-transfer כדי להנפיק את פרטי הכניסה לכל שחקן.
    • אם אתם משתמשים בסביבת זמן הריצה של microVM, תנו לחשבון השירות atelet של Kubernetes את התפקיד "צפייה באובייקט אחסון" (roles/storage.objectViewer) בקטגוריית הנכסים.

    הרשימה המלאה של הקישורים ופקודות gcloud המקבילות מופיעה בקטע What create iam actually grants בקובץ README של setup-gcp.

  • משפחות של מכונות וירטואליות:

    • ארכיטקטורות מעורבות של מעבדים (CPU): בגלל בעיה ידועה ב-gVisor, אי אפשר להשתמש ב-Agent Substrate ב-GKE עם סדרות של מכונות למטרות כלליות שפועלות בארכיטקטורות מעורבות של מעבדים (כמו סוגי מכונות E2).
    • סוגי מכונות וירטואליות אחידים לכל תבנית של Actor: כל ה-Actors שאתם יוצרים מ-ActorTemplate אחד חייבים לפעול באותו סוג של מכונה וירטואלית. ‫ActorTemplate הוא לא משאב ב-Kubernetes ואין לו בורר צמתים. במקום זאת, השדה workerSelector של ActorTemplate בוחר משאבים מסוג WorkerPool לפי התוויות שלהם. כל WorkerPool יכול לבחור את הצמתים של ה-Workers שלו באמצעות השדה spec.template.nodeSelector. לדוגמה, אם באשכול יש מאגרי צמתים שמשתמשים במכונות וירטואליות מסוג C4 ומסוג N2, צריך להגדיר כל WorkerPool כך שיבחר צמתים רק מסוג אחד של מכונה וירטואלית. אחר כך מגדירים את השדה workerSelector של ActorTemplate כך שיתאים רק למשאבי WorkerPool שמשתמשים במכונות וירטואליות מסוג C4.
    • וירטואליזציה בתצורה מקוננת או שרתים פיזיים לסביבות זמן ריצה של microVM: סביבת זמן הריצה של microVM מריצה כל ארגז חול במכונה וירטואלית משלו, ולכן Workers שמשתמשים בסביבת זמן הריצה הזו צריכים צמתים שיכולים להריץ מכונות וירטואליות. הצמתים האלה חייבים להשתמש בארכיטקטורת מעבד (CPU) מסוג x86, ולא Arm. כשמתקין יוצר אשכול, מאגר הצמתים שהוא יוצר מופעל עם וירטואליזציה בתצורה מקוננת. אם אתם מתקינים את Agent Substrate ב-GKE באשכול קיים או מוסיפים מאגרי צמתים משלכם ל-microVM Workers, השתמשו במאגר צמתים שמופעלת בו וירטואליזציה בתצורה מקוננת או שמשתמש בסוג מכונה פיזית x86. אפשר להפעיל וירטואליזציה בתצורה מקוננת רק כשיוצרים מאגר צמתים. כדי לבדוק אילו סדרות מכונות תומכות בווירטואליזציה בתצורה משולבת, כמו C3,‏ C4,‏ N2 ו-N4, קראו את המאמר השוואה בין סדרות מכונות.

  • תמיכה ב-GPU: אי אפשר להעביר מכשיר GPU לקונטיינרים של Actor. אם מציינים רק את nvidia.com/gpu, ה-Pods ממוקמים רק בצמתים עם GPU, אבל מכשיר ה-GPU לא מועבר למאגר של ה-Actor. בנוסף, gVisor לא יכול ליצור קובץ snapshot של הקשרי CUDA פעילים.

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

  • ‫Observability ו-Managed OpenTelemetry: ל-Managed OpenTelemetry ל-GKE יש את המגבלות הבאות:

    • אין תמיכה במחברי איסוף, ולכן צריך להשתמש במונה פרוקסי חיצוני למדידת טלמטריה.
    • פריסות של Collector גורמות לתקורה של מטמון הזיכרון, שמשתנה באופן לינארי בהתאם למספר ה-Pods באשכולות גדולים.
    • אין תמיכה ב-TLS ב-Managed OpenTelemetry ל-GKE.

  • אחסון: Agent Substrate ב-GKE משתמש בקטגוריות הבאות של Cloud Storage, שנוצרות על ידי תוכנת ההתקנה אם הן לא קיימות:

    • קטגוריית תמונת מצב: מאחסנת את תמונות המצב של כל הסוכנים באשכול. הקטגוריה הזו נדרשת.
    • קטגוריית נכסים: מאחסנת את הקבצים שנדרשים לסביבת זמן הריצה של ה-microVM, כמו ליבת Linux ומערכת קבצים בסיסית. סביבת זמן הריצה של microVM משתמשת בקבצים האלה כדי להריץ כל ארגז חול במכונה וירטואלית משלו. השם של הקטגוריה הזו הוא השם של קטגוריית קובץ ה-snapshot, ואחריו -assets. לדוגמה, אם קטגוריית תמונת המצב נקראת example-snapshots, קטגוריית הנכסים נקראת example-snapshots-assets. אם לא משתמשים בסביבת זמן הריצה של microVM, הקטגוריה הזו נשארת ריקה.

  • הגדרות ליבה לצפיפות גבוהה של ארגזי חול: הפעלה של יותר מ-800 ארגזי חול בו-זמנית בצומת חורגת ממגבלות ברירת המחדל בליבת Linux למעקב אחר מערכת הקבצים (inotify) ולטבלת השכנים של Address Resolution Protocol‏ (ARP). בלי מגבלות גבוהות יותר, יכול להיות שארגזי החול לא יתחילו לפעול ושהרשת תתעכב. מנהל ההתקנה מחיל את הגדרות הליבה הנדרשות על האשכולות שהוא יוצר. אם אתם מתקינים את Agent Substrate ב-GKE באשכול קיים או מוסיפים מאגרי צמתים משלכם, אתם צריכים להחיל את ההגדרות האלה בעצמכם. הערכים הנדרשים מפורטים במאמרים דרישות האשכול ותכנון התשתית ל-Agent Substrate ב-GKE.

  • סביבת ההתקנה: אי אפשר להתקין את Agent Substrate ב-GKE ב-Cloud Shell. ב-Cloud Shell יש מגבלת אחסון של 5GB מקום בכונן מתמיד (persistent disk), שלא מספיקה להתקנה. צריך להתקין את Agent Substrate ב-GKE מתחנת עבודה מקומית או ממכונה וירטואלית (VM) עם מספיק מקום בכונן.

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