ב-Google Kubernetes Engine (GKE) יש שני מודלים של תזמור להרצת סוכני AI בתוך ארגזי חול מבודדים ברמת הליבה (באמצעות Cloud Hypervisor microVMs או gVisor):
- Agent Substrate ב-GKE (מבוסס-שחקן, מומלץ): מודל שמתאים לרוב עומסי העבודה של סוכני AI, במיוחד סוכנים מבוססי-CPU עם שמירת מצב (stateful) שמושהים ומופעלים מחדש לעיתים קרובות. סשנים פעילים של סוכנים (שחקנים) חולקים מאגר של פודים פעילים של עובדים, ואפשר לשחזר אותם מ-Cloud Storage תוך פחות משנייה.
- Agent Sandbox ב-GKE (מבוסס-Pod): משתמשים במודל הזה כשכל סוכן דורש Pod ייעודי של Kubernetes. כדאי לבחור באפשרות הזו לסוכנים פעילים באופן רציף או לעומסי עבודה שצריכים PodSpec מלא של Kubernetes (כמו sidecars), יחידות GPU או TPU, צומתי Arm או אשכולות של GKE Autopilot.
במאמר השוואה בין Agent Substrate ל-Agent Sandbox מופיע סיכום של שני המודלים לתזמור.
כדאי לקרוא את המסמך הזה כדי לבחור מודל תזמור, סביבת זמן ריצה של ארגז חול, אמצעי בקרה לבידוד ואפשרויות אחסון לפני הקצאת אשכול GKE. המסמך הזה מיועד לאדריכלי פתרונות, למפתחי AI, לאדמינים ולמפעילי פלטפורמות שמתכננים סביבות הרצה לסוכני AI ב-GKE.
דרישות ארכיטקטוניות לעומסי עבודה של סוכני AI ב-GKE
כשמריצים עומסי עבודה של סוכני AI ב-GKE, אפשר למקם סביבות מבודדות להרצת סוכנים באותו אשכול ובאותו היקף רשת כמו שירותי Kubernetes התומכים, ולהשתמש ב-GKE להקצאת צמתים אוטומטית, להרחבה פתאומית ולניהול מחזור החיים.
בניגוד למיקרו-שירותים שפועלים באופן רציף, לעומסי העבודה של סוכני AI יש את הדרישות הארכיטקטוניות הבאות:
- הרצת קוד לא מהימן: סוכנים שיוצרים ומריצים קוד או פקודות מעטפת צריכים בידוד של הליבה, פרטי הכניסה והרשת בין הסשנים. בשני המודלים של התזמור, הסשנים של הסוכנים מבודדים מהקרנל של המארח באמצעות מכונות מיקרו-וירטואליות או gVisor, ואפשר להגביל את פרטי הכניסה ותעבורת הנתונים היוצאת ברשת ב-Agent Substrate או את פרטי הכניסה ומדיניות הרשת ב-Agent Sandbox.
- יחסים גבוהים של חוסר פעילות: עוזרים אינטראקטיביים לעזרה בתכנות וסוכני פרודוקטיביות ברקע מבלים את רוב מחזור החיים שלהם בהמתנה לקלט אנושי, להסקת מודלים או לתגובות של כלים. גם ב-Agent Substrate וגם ב-Agent Sandbox, נציג פעיל משתמש במשאבי המחשוב עד שהאפליקציה משעה אותו.
- שינויים מהירים בסביבה: פלטפורמות של סוכנים יוצרות, משעות, מפעילות מחדש או עוצרות לעיתים קרובות מספר גדול של סביבות בפרצי פעילות. כדי לשמור על קיבולת הצמתים מוכנה לעומסים פתאומיים של פודים של WorkerPool ב-Agent Substrate או של פודים של SandboxWarmPool ב-Agent Sandbox, השתמשו ב-ComputeClasses בהתאמה אישית של GKE כדי להקצות משאבים לצמתים באופן אוטומטי, ובמאגרים זמניים למשאבי מחשוב כדי לשמור קיבולת במצב המתנה.
- השהיה והמשך מהירים של מצב: סוכנים עם שמירת מצב צריכים ליצור נקודות ביקורת ולשחזר את זיכרון העבודה (RAM) ואת קובצי סביבת העבודה בלי לבנות מחדש את הסביבות מאפס. GKE משתלב עם Cloud Storage, Filestore ו-Google Cloud Hyperdisk כדי לתמוך בנקודות ביקורת של סשנים ובאחסון של סביבות עבודה ב-Agent Substrate, ובתמונות מצב של Pods ובאחסון מתמיד ב-Agent Sandbox.
מודל מבוסס-שחקן: Agent Substrate ב-GKE (מומלץ)
Agent Substrate ב-GKE הוא סביבת זמן ריצה שמפרידה בין סשנים של סוכנים (שחקנים) לבין Pods ב-Kubernetes. ה-actors הפעילים משתפים מאגר של פודים של וורקרים שחוממו מראש (משאבי WorkerPool) בין תבניות של actors (משאבי ActorTemplate). כשהאפליקציה משעה אקטור לא פעיל, Agent Substrate יוצר נקודת ביקורת של מצב האקטור ב-Cloud Storage ומשחרר את קיבולת ה-worker שלו כדי שאקטורים אחרים יוכלו להשתמש בצומת. כשמגיעה בקשה חדשה, Agent Substrate משחזר את ה-actor ל-worker זמין תוך פחות משנייה.
כדאי להשתמש ב-Agent Substrate כארכיטקטורת ברירת המחדל לעומסי עבודה של סוכנים שמבוססים על מעבד (CPU), כולל בתרחישים הבאים:
- סוכני תכנות אינטראקטיביים: עוזרים אישיים מבוססי-AI שמריצים פקודות טרמינל, יוצרים קוד ועורכים קבצים במהלך שיחות עם מפתחים, ומשהים את הפעילות בין הנחיות.
- סוכני פרודוקטיביות שפועלים לאורך זמן: עוזרים דיגיטליים שפועלים ברקע ושומרים על ההקשר במשך ימים או שבועות, ומבלים את רוב הזמן בהמתנה לקלט מהמשתמש או לטריגרים חיצוניים.
- קוד זמני וארגזי חול בדפדפן: סביבות לפי דרישה להרצת קוד שנוצר על ידי LLM, דפדפנים ללא ממשק משתמש או קריאות API לכלי שמשחזרים תוך פחות משנייה ומשחררים את המחשוב אחרי ההרצה.
כדי להשתמש ב-Agent Substrate, צריך אשכולות GKE Standard (גרסה 1.37 ואילך גם במישור הבקרה וגם במאגרי הצמתים) עם צומתי עובדים של מעבד x86. אי אפשר להשתמש ב-GKE Autopilot כי סוכן הצומת של Agent Substrate (atelet) פועל כ-DaemonSet עם הרשאות, ומאגרי ה-workers של microVM דורשים וירטואליזציה בתצורה מקוננת או צמתים של Bare Metal. אין תמיכה ב-GPU וב-TPU.
זהות, פרטי כניסה ותעבורת נתונים יוצאת ברשת
Agent Substrate מקצה אישור SPIFFE X.509 ייחודי ו-JSON Web Token (JWT) לכל גורם כדי לאמת ולבדוק בקשות מסשנים ספציפיים. בגלל שכמה גורמים משתפים Pods של וורקרים לאורך זמן, צריך להשתמש באיחוד זהויות של עומסי עבודה ל-GKE ברמת ה-Pod רק למשימות תשתית של וורקרים.
כדי לשמור את מפתחות ה-API והאסימונים מחוץ לארגז החול, שער היציאה המובנה מוסיף את פרטי הכניסה לבקשות היוצאות בזמן ההעברה. אתם מאחסנים סודות באובייקטים של Kubernetes Secret או ב-Secret Manager. כשבקשת HTTP או HTTPS יוצאת תואמת לכלל תעבורת נתונים יוצאת, השער מאמת את מנהרת ה-mTLS של השחקן ומחליף את כותרות הפלייסהולדר בסוד שנשלף או ב-JWT של השחקן. מידע נוסף זמין במסמכי התיעוד של Agent Substrate בקוד פתוח בנושא הזרקת פרטי כניסה לתעבורת נתונים יוצאת.
כברירת מחדל, Agent Substrate חוסם את כל תעבורת הנתונים היוצאת לגורמים אחרים, למישור הבקרה של Kubernetes, לשרת המטא-נתונים של Compute Engine ולאינטרנט. חיבורי UDP שאינם DNS, חיבורי TCP גולמיים שרירותיים ושדרוגי HTTP WebSocket חסומים, ו-DNS פותר רק שמות מארחים שמותרים על ידי המשאב EgressPolicy של השחקן. כדי לאפשר חיבורים יוצאים, מגדירים כללי מעבר של HTTP, HTTPS או TLS במשאב EgressPolicy באמצעות שמות דומיין שמוגדרים במלואם (FQDN) או שמות מארחים עם תווים כלליים לחיפוש. אין תמיכה בכתובות IP ובטווחי CIDR. מידע נוסף זמין במסמכי התיעוד של Agent Substrate בקוד פתוח בנושא תנועת נתונים יוצאת ואבטחה.
נקודות ביקורת של סשנים ונפח האחסון בסביבת העבודה
כשהאפליקציה משעה שחקן (ב-gVisor או במיקרו-VM), המערכת של Agent Substrate שומרת תמונת מצב ב-Cloud Storage בשלוש שכבות: זיכרון פעיל, שינויים במערכת הקבצים ברמה הבסיסית (root) וספריות עמידות (שכבת הנפחים). כל אמצעי האחסון החיצוניים של CSI שמצורפים נשארים באחסון הגיבוי שלהם מחוץ לתמונת המצב, ומצורפים מחדש בהמשך.
כשהפעילות של אקטור מושעה מתחדשת, Agent Substrate משחזר את שכבת תמונת המצב הגבוהה ביותר שתואמת לסביבת היעד:
- זיכרון, מערכת קבצים בסיסית ונפחים: משוחזרים תוך פחות משנייה כשהשחקן ממשיך עם אותה חומרה, זמן ריצה של ארגז חול וקובץ אימג' של קונטיינר.
- מערכת קבצים בסיסית ואמצעי אחסון: משוחזרים כשחומרת הצומת או סביבת זמן הריצה של ארגז החול משתנות. הגורם מפעיל מחדש את התהליכים שלו תוך שמירה על השינויים במערכת הקבצים ברמה הבסיסית (root) ועל הספריות העמידות.
- אמצעי אחסון בלבד: משוחזרים כשמעדכנים את קובץ האימג' של הקונטיינר במשאב ActorTemplate בזמן שה-actor מושעה. בפעם הבאה שתמשיכו את העבודה, הקונטיינרים יופעלו מהאימג' המעודכן, והספריות העמידות ואמצעי האחסון החיצוניים ישוחזרו. כדאי לכתוב נתונים שצריכים להישמר אחרי עדכוני תמונות בספריות עמידות או באחסון חיצוני.
זמן ההשהיה וההמשך משתנה בהתאם לגודל קובץ ה-snapshot. בסביבות עבודה גדולות שצריך לצרף מחדש במהירות בין צמתים כשהשחקן ממשיך בצומת אחר, כדאי להשתמש בנפחי אחסון חיצוניים של סוכני Filestore במקום לאחסן את הנתונים בתוך תמונת המצב. כל אמצעי אחסון חיצוני של CSI (גרסת טרום-השקה (Preview)) במשאב ActorTemplate מוקצה באופן בלעדי לשחקן אחד (לא משותף בין שחקנים) ונמחק יחד עם השחקן הזה. תמיכה ב-Production בנפחי אחסון לסוכנים ב-Filestore מוצעת במסגרת תוכנית GA מוגבלת, שצריך לשלוח בקשת גישה כדי להצטרף אליה.
אחסון בלוקים (כמו Hyperdisk) משמש לדיסקים של אתחול צמתים ולשמירה במטמון של קובצי snapshot מקומיים, ולא לנפחי CSI לכל שחקן, כי זמן האחזור של ניתוק וחיבור של בלוקים בין צמתים מאט את החזרה של השחקנים לפעילות. מידע נוסף זמין במסמכי התיעוד של Agent Substrate CSI בקוד פתוח.
מודל מבוסס-Pod: Agent Sandbox ב-GKE
ארגז החול לסוכנים ב-GKE מריץ כל סוכן ב-Kubernetes Pod ייעודי עם שמירת מצב, שמנוהל באמצעות משאבים בהתאמה אישית של Kubernetes (Sandbox, SandboxClaim, SandboxTemplate ו-SandboxWarmPool). משאב SandboxWarmPool מתחזק משאבי Sandbox שחוממו מראש עם Pods פועלים למשאב SandboxTemplate ספציפי, כדי שהבקר יוכל להקצות משאב Sandbox מוכן ואת ה-Pod הפועל שלו לתביעה בפחות משנייה.
כדאי לבחור ב-Agent Sandbox כשכל סוכן צריך Pod ייעודי או כשעומסי העבודה עומדים בדרישות הבאות:
- סוכנים שפועלים באופן רציף ושירותים עם Pod יחיד: עומסי עבודה בלי תקופות ארוכות של חוסר פעילות, או סשנים מתמשכים (כמו סביבות פיתוח בענן או Jupyter Notebooks) שצריכים שם מארח יציב ואחסון בלי המורכבות של StatefulSet.
- שיפור מהירות באמצעות חומרה (GPU או TPU): סוכנים שצריכים גישה ישירה ל-GPU או ל-TPU בתוך ארגז החול. מאיצים פועלים רק עם סביבת זמן הריצה של gVisor בדגמי GPU ובגרסאות TPU נתמכים. במכונות MicroVM אין תמיכה ב-GPU או ב-TPU.
- Kubernetes PodSpec מלא, צומתי Arm או GKE Autopilot: עומסי עבודה שדורשים קונטיינרים מסוג sidecar או init בהתאמה אישית, ממשקי API וכלים סטנדרטיים של Kubernetes (לדוגמה, פקודות
kubectl, בקרת גישה המבוססת על תפקידים (RBAC) ובקרים קיימים), מעבדי Arm או אשכולות GKE Autopilot.
מדיניות בנושא זהות, פרטי כניסה ומדיניות רשת ב-Kubernetes
כל סוכן פועל ב-Pod ייעודי, ולכן אתם יכולים לתת ל-Pod הרשאות Google Cloudלניהול זהויות והרשאות גישה (IAM) באמצעות איחוד זהויות של עומסי עבודה ל-GKE או Agent Identity (גרסת טרום-השקה (Preview)). בשתי האפשרויות, הזהות מקושרת ל-Kubernetes ServiceAccount של ה-Pod בזמן היצירה שלו, כך שכל ה-Pods שחוממו מראש במשאב SandboxWarmPool חולקים את אותה זהות. כדי לבודד זהויות לכל נציג או דייר, צריך לשמור משאב SandboxWarmPool נפרד לכל זהות או ליצור משאבי Sandbox לפי דרישה בלי מאגר חם.
כדי לטעון סודות ל-Pods, משתמשים באובייקטים רגילים של Kubernetes Secret או בנפחי CSI. ב-Agent Sandbox אין שער להזרקת פרטי כניסה מחוץ לארגז החול. כדי להוסיף פרטי כניסה במעבר, צריך לפרוס שרת proxy חיצוני משלכם.
הבקר יוצר אובייקט NetworkPolicy עם דחייה כברירת מחדל לכל משאב SandboxTemplate. למשאבי Sandbox שאתם יוצרים ישירות בלי תבנית, צרו אובייקט NetworkPolicy משלכם. כדי להגביל את התנועה, משתמשים באמצעי הבקרה הרגילים של הרשת ב-GKE:
- שכבה 4: הגבלת התנועה בין Pod ל-Pod ותנועת ה-IP באמצעות מדיניות הרשת ב-GKE (אובייקטים של NetworkPolicy).
- שכבה 7: הגבלת החיבורים היוצאים לדומיינים שאושרו באמצעות מדיניות רשת ב-Kubernetes עם FQDN (אובייקטים של FQDNNetworkPolicy).
השעיה במצב חוסר פעילות, תמונות מצב של Pod ואחסון
ה-Pod של סוכן לא פעיל שומר על המעבד (CPU) והזיכרון שהוקצו לו עד שהאפליקציה משעה את המשאב של ארגז החול על ידי הגדרת השדה spec.operatingMode שלו לערך Suspended. השעיית המשאב של ארגז החול מוחקת את ה-Pod, אבל שומרת על אמצעי האחסון הקבועים שלו. מחיקת ה-Pod מנקה את הנתונים בזיכרון ואת השינויים במערכת הקבצים של הקונטיינר. כדי לשמור את המצב הזה ולשחזר אותו מ-Cloud Storage, צריך ליצור תמונת מצב של Pod ב-GKE לפני שמשהים את הנציג. כדי ליצור קובצי snapshot של Pod, צריך להשתמש בסביבת זמן הריצה של gVisor. אי אפשר להשתמש ב-microVM או ב-TPU. שחזור Pod מתמונת מצב נמשך בערך שלוש עד חמש שניות.
כדי להשתמש באחסון מתמיד מעבר לתמונות המצב של Pod, אתם יכולים לבחור מבין האפשרויות הבאות:
- Filestore: טעינת PersistentVolumeClaim (PVC) משותף של
ReadWriteMany(RWX) בכמה פודים של ארגז חול לסביבות עבודה משותפות. מידע נוסף מופיע במאמר בחירת אחסון לעומסי עבודה של סוכני AI. - Hyperdisk: משתמשים ב-Google Cloud Hyperdisk Balanced (מצב גישה
ReadWriteOnce) לדיסקים מבודדים של Pod, או ב-Google Cloud Hyperdisk ML (מצב גישהReadOnlyMany) כדי לשתף מערכי נתונים לקריאה בלבד או משקלי מודלים בין צמתים. מידע נוסף זמין במאמרים בחירת אחסון לעומסי עבודה של סוכני AI ומידע על Hyperdisk ל-GKE.
השוואה בין Agent Substrate לבין Agent Sandbox
בטבלה הבאה מפורטים ההבדלים בארכיטקטורה בין Agent Substrate ב-GKE לבין Agent Sandbox ב-GKE:
| מאפיין | Agent Substrate ב-GKE (מבוסס-שחקן) | Agent Sandbox ב-GKE (מבוסס-Pod) |
|---|---|---|
| עומסי עבודה מומלצים לסוכני AI | רוב הסוכנים מבוססי המעבד (CPU) עם שמירת מצב, שמושעים ומופעלים מחדש לעיתים קרובות | סוכנים שפועלים באופן רציף, עומסי עבודה של GPU או TPU, מפרטי PodSpecs בהתאמה אישית, צומתי Arm או GKE Autopilot |
| יחידת תזמון | כמה גורמים משתפים מאגר של פודים חמים (WorkerPool) | Pod ייעודי אחד לכל נציג (ארגז חול) |
| זמני ריצה של ארגז חול | מכונות וירטואליות זעירות של gVisor ו-Cloud Hypervisor (מנוהלות בתוך פודים של WorkerPool) | gVisor ומכונות מיקרו-VM ב-GKE Standard (עם GKE Sandbox שמופעל במאגר הצמתים או ב-ComputeClass), או gVisor ב-GKE Autopilot (מופעל כברירת מחדל) |
| מאגר חם | משאבים משותפים של WorkerPool בתבניות של שחקנים ובקובצי אימג' של קונטיינרים | משאב SandboxWarmPool אחד לכל תבנית וקובץ אימג' של קונטיינר |
| נתיב מישור הבקרה |
מישור בקרה ומסד נתונים ייעודיים מחוץ לרכיב kube-apiserver
|
בקרים סטנדרטיים של Kubernetes, kube-apiserver ו-etcd
|
| טיפול במשאבים לא פעילים | השעיית שחקן לא פעיל משחררת את המעבד והזיכרון של ה-worker שלו | השעיית משאב Sandbox לא פעיל מוחקת את ה-Pod שלו ושומרת על אמצעי אחסון קבועים |
| נקודות ביקורת של המדינה | תמונות מצב מובנות של Cloud Storage ב-gVisor ובמיקרו-VM, שחזור בפחות משנייה | תמונות מצב של Pod ב-GKE (נתמכות רק ב-gVisor), שחזור תוך 3-5 שניות |
| מצבי אשכול נתמכים | GKE Standard (גרסה 1.37 ואילך, צומתי x86) | GKE Standard ו-GKE Autopilot |
| מאיצי חומרה | לא נתמך (צומתי עובד עם מעבד בלבד) | יחידות GPU ו-TPU נתמכות רק בסביבת זמן הריצה של gVisor |
| תמיכה ב-Kubernetes PodSpec | קבוצת משנה שמפוצלת בין המשאבים ActorTemplate ו-WorkerPool | PodSpec מלא, כולל קונטיינרים של sidecar ו-init |
| Networking | שערי כניסה ויציאה מובנים של Envoy עם מנהרות mTLS לכל גורם | שירותי Kubernetes, NetworkPolicy ו-FQDNNetworkPolicy |
| מודל הזהות | אישור SPIFFE X.509 ו-JWT לכל גורם | Pod ServiceAccount באמצעות איחוד זהויות של עומסי עבודה ל-GKE או Agent Identity (גרסת טרום-השקה (Preview)), שמשותף למאגר חם |
| ניהול סודות | מוזרק לבקשות יוצאות בשער היציאה | התקנה ב-Pod באמצעות אובייקטים של Kubernetes Secret או נפחי CSI |
בחירת סביבת זמן ריצה של ארגז חול
גם Agent Substrate וגם Agent Sandbox מבודדים קוד לא מהימן מצומת המארח באמצעות מכונות וירטואליות זעירות של Cloud Hypervisor או gVisor, אבל מגדירים את סביבת זמן הריצה באופן שונה בכל מודל:
- Agent Substrate: בוחרים את סביבת זמן הריצה במשאב WorkerPool. Agent Substrate מנהל את סביבות זמן הריצה של microVM ו-gVisor בתוך ה-Pods של WorkerPool, במקום להשתמש בתכונה GKE Sandbox ברמת הצומת.
אל תפעילו את GKE Sandbox במאגרי צומתי העובדים של Agent Substrate, כי הכתם
sandbox.gke.io/runtimeשל הצומת מונע את התזמון של פודים של WorkerPool. - Agent Sandbox: מגדירים את השדה
runtimeClassNameלערךgvisorאוmicrovmבתבנית Pod של המשאב SandboxTemplate. ב-GKE Standard, צריך להפעיל את GKE Sandbox גם במאגר הצמתים או ב-ComputeClass בהתאמה אישית. ב-GKE Autopilot, gVisor זמין כברירת מחדל ואין תמיכה במיקרו-VM.
שתי סביבות זמן הריצה מריצות קוד לא מהימן ודפדפנים ללא ממשק משתמש:
- MicroVMs: כל ארגז חול פועל במכונה וירטואלית קלה עם ליבת Linux ייעודית לאורחים. בחרו ב-microVMs כשאתם צריכים בידוד ברמת ה-VM, תאימות מלאה ל-syscall של Linux או מגבלות מעבד וזיכרון לכל קונטיינר בתוך actor עם כמה קונטיינרים.
- gVisor: כל ארגז חול פועל בליבה של סביבת המשתמש שמיירטת ומסננת קריאות מערכת (syscalls) של Linux. כדאי לבחור ב-gVisor כדי ליהנות מהפעלה מהירה יותר במצב התחלתי (cold start), תקורה נמוכה יותר של זיכרון או תמיכה רחבה יותר במכונות של Compute Engine (כולל GPUs, TPUs, צומתי Arm ו-GKE Autopilot ב-Agent Sandbox).
בטבלה הבאה מוצגת השוואה בין מכונות מיקרו-VM לבין gVisor ב-GKE:
| תכונה | MicroVMs | gVisor |
|---|---|---|
| גישה לליבה (kernel) | ליבת Linux מלאה | קבוצת משנה של קריאות מערכת (syscalls) של ליבת Linux |
| רמת הבידוד | וירטואליזציה של חומרה עם ליבת אורח ייעודית | יירוט קריאות מערכת בקרנל של מרחב המשתמש |
| תקורה של מעבד (CPU) וזיכרון | זיכרון VMM לכל שחקן ב-Agent Substrate. 250mCPU ו-130MiB לכל Pod ב-GKE Sandbox. | תקורה דינמית עם זיכרון בסיס נמוך |
| שעת ההתחלה | שנייה עד שתי שניות | פחות מ-100 אלפיות השנייה |
| הגדרת צומת GKE | צמתים של GKE Standard עם וירטואליזציה בתצורה משורשרת (שני המודלים), או צמתים של שרת פיזי x86 (רק Agent Substrate) | מאגרי צמתים של GKE Standard (שני המודלים) או צמתים של GKE Autopilot (רק Agent Sandbox) |
| תמיכה בתמונות של צמתים |
מערכת הפעלה שמותאמת לקונטיינרים (cos_containerd) ב-Agent Substrate. מערכת הפעלה שמותאמת לקונטיינרים (cos_containerd) או Ubuntu ב-GKE Sandbox.
|
מערכת הפעלה שמותאמת לקונטיינרים (cos_containerd) בלבד
|
| תאימות לסוג המכונה | סדרות מכונות x86 שתומכות בווירטואליזציה בתצורה מקוננת, ו-bare metal x86 (לא נתמך ב-E2 או ב-Arm) | סדרת x86 עם מעבדים (CPU) לא מעורבים ב-Agent Substrate. רוב סדרות x86, Arm והמאיצים ב-Agent Sandbox. |
| תמיכה במאיצים | לא נתמך | דגמי GPU וגרסאות TPU נתמכים (Agent Sandbox בלבד) |
| תרחישים לדוגמה |
|
|
למידע נוסף על טכנולוגיות הבידוד האלה, ראו GKE Sandbox.
המאמרים הבאים
- מידע נוסף על מחזורי החיים של שחקנים זמין במאמר מידע על Agent Substrate ב-GKE.
- מתקינים את Agent Substrate ב-GKE.
- איך מתכננים את התשתית ל-Agent Substrate ב-GKE
- מידע נוסף על ארגזי חול מבוססי-Pod זמין במאמר מידע על Agent Sandbox ב-GKE.
- התקנת Agent Sandbox ב-GKE