התקנת Agent Substrate ב-GKE

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

במאמר הזה מוסבר איך להכין את הפרויקט ב- Google Cloud ואת אשכול GKE ל-Agent Substrate ב-GKE, איך להריץ את תוכנת ההתקנה ואילו משאבים נוצרים בהתקנה.

תמחור

‫Agent Substrate ב-GKE מוצע ללא תשלום נוסף. התמחור של GKE חל על המשאבים שאתם יוצרים.

מגבלות

אלה מגבלות ההתקנה של Agent Substrate ב-GKE:

  • ‫Cloud Shell: אי אפשר להתקין את Agent Substrate ב-GKE ב-Cloud Shell כי Cloud Shell מספק 5GB של אחסון בדיסק מתמיד (persistent disk), וזה לא מספיק להתקנה. צריך להריץ את תוכנת ההתקנה במחשב המקומי.
  • מצב אשכול: אפשר להתקין את Agent Substrate ב-GKE רק באשכולות GKE Standard. אין תמיכה באשכולות Autopilot.
  • ‫Cluster version: גם מישור הבקרה וגם מאגרי הצמתים באשכול צריכים לפעול ב-GKE בגרסה 1.37 ואילך. גרסאות ישנות יותר מ-1.37 לא נתמכות.
  • ערוץ הפצה: אי אפשר להתקין את Agent Substrate ב-GKE באשכולות שרשומים לערוץ ההפצה המורחב. תוכנת ההתקנה מפעילה ממשקי API של Kubernetes בגרסת בטא באשכול, ובערוץ המורחב אין תמיכה בממשקי API בגרסת בטא שהופעלו באופן מפורש.
  • סוגי מכונות: אי אפשר להשתמש בסדרות מכונות שפועלות על ארכיטקטורות מעורבות של מעבדים (כמו סוגי מכונות E2).

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
  • מתקינים את הרכיבים הבאים ב-CLI של gcloud:
    • kubectl
    • gke-gcloud-auth-plugin
  • מוודאים שהכלים הבאים מותקנים במחשב המקומי:
    • ‫Git כדי לשכפל את המאגר של Agent Substrate.
    • Go כדי להריץ את התוכניות של תוכנת ההתקנה, שמופצות כקוד מקור.
    • ‫make כדי להפעיל את מנהל ההתקנה.
    • ‫Docker והפלאגין Buildx שלו, כדי ליצור את קובצי האימג' של קונטיינר Agent Substrate ב-GKE.
    • ‫sha256sum, zstd, unzip ו-jq כדי להגדיר את סביבת זמן הריצה של microVM, אם אתם מתכננים להשתמש בה. אם אחד מהכלים האלה חסר, תוכנית ההתקנה לא מציעה את סביבת זמן הריצה של microVM.

  • כדי לאפשר למתקין לדחוף את קובצי האימג' שהוא יוצר, צריך להגדיר את Docker לאימות ב-Artifact Registry באזור של האשכול:

    gcloud auth configure-docker REGION-docker.pkg.dev

    מחליפים את REGION באזור של האשכול, למשל us-west1. למידע נוסף, קראו את המאמר הגדרת אימות ל-Artifact Registry בשביל Docker.

  • מכיוון שההתקנה פועלת בשמכם כדי להפעיל ממשקי API ולהקצות משאבים, צריך להגדיר את Application Default Credentials‏ (ADC) באמצעות הפקודה הבאה:

    gcloud auth application-default login

    מידע נוסף על אימות באמצעות ADC זמין במאמר הגדרת Application Default Credentials.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להתקנת Agent Substrate ב-GKE, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט:

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

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

דרישות לגבי אשכולות

אם תאפשרו למתקין ליצור בשבילכם אשכול, הוא יגדיר באופן אוטומטי אשכול שעומד בכל הדרישות של Agent Substrate ב-GKE.

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

  • פועל ב-GKE Standard (יש תמיכה ב-Agent Substrate ב-GKE רק באשכולות Standard).
  • מריץ את GKE בגרסה 1.37 ואילך גם במישור הבקרה וגם במאגרי הצמתים. אם במישור הבקרה פועלת גרסה קודמת, קודם צריך לשדרג את מישור הבקרה. לאחר מכן, שדרגו את כל מאגרי הצמתים שפועלת בהם גרסה קודמת, כדי שהצמתים יוכלו לטעון אישורי Pod ל-Pods.
  • לא רשום לערוץ ההפצה המורחב. מידע נוסף מופיע בקטע מגבלות.
  • משתמש ב-GKE Dataplane V2.
  • משתמש במכונות מסוג c3-standard-4 או גדולות יותר לצמתים.

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

    • net.ipv4.neigh.default.gc_thresh1: 4096
    • net.ipv4.neigh.default.gc_thresh2: ‏16384
    • net.ipv4.neigh.default.gc_thresh3: ‏32768
    • fs.inotify.max_user_instances: ‏65536
    • fs.inotify.max_user_watches: 1048576

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

איך מתקינים את Agent Substrate ב-GKE

כדי להתקין את Agent Substrate ב-GKE, מריצים את אחת מהפקודות הבאות בטרמינל המקומי:

  • כדי להתקין את הסוכן לעומסי העבודה שלכם, מריצים את הפקודה הבאה:

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash

  • כדי להתקין את הדגמת המונה ולנסות אותה, מריצים את הפקודה הבאה:

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash -s -- --demo

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

  • קובצי אימג' של קונטיינרים (חובה): כשמנהל ההתקנה מבקש לבחור את קובצי האימג', בוחרים באפשרות Build from source. ההתקנה יוצרת את קובצי האימג' ממאגר Agent Substrate במעלה הזרם ומעבירה אותם למאגר Artifact Registry בפרויקט. כברירת מחדל, תוכנית ההתקנה יוצרת את הגרסה העדכנית של Agent Substrate. כדי ליצור גרסה אחרת, מזינים הסתעפות, תג או SHA מלא של commit מהמאגר במעלה הזרם.
  • מזהה פרויקט (חובה): ציין את ה- Google Cloud פרויקט שבו יוקצו המשאבים. אם הגדרתם פרויקט ברירת מחדל ל-CLI של gcloud, תוכנת ההתקנה תשתמש במזהה הפרויקט הזה.
  • ‫Cluster (חובה): בוחרים אם לאפשר למתקין ליצור אשכול GKE חדש עם ברירות מחדל מומלצות, או להתקין את Agent Substrate ב-GKE באשכול קיים. אם בחרתם להתקין באשכול קיים, ודאו שהוא עומד בדרישות שמפורטות בקטע דרישות האשכול.
  • ‫Snapshot bucket (אופציונלי): מציינים שם מותאם אישית לקטגוריה של Cloud Storage, או משאירים את השדה ריק כדי לאפשר למתקין ליצור קטגוריית ברירת מחדל בשם ate-snapshots-<project>-<cluster>-<zone>. שם ברירת המחדל כולל את שם האשכול, ולכן אשכולות באותו פרויקט ובאותו אזור לא חולקים קטגוריה. שם בהתאמה אישית יכול להכיל עד 56 תווים, כי תוכנת ההתקנה גם יוצרת קטגוריית נכסים על ידי הוספת הסיומת -assets לשם, ושמות של קטגוריות יכולים להכיל עד 63 תווים. אם שם ברירת המחדל ארוך מ-56 תווים, תוכנת ההתקנה מקצרת אותו ומוסיפה לו גיבוב (hash).
  • לקוחות Ingress (חובה): מזינים את מזהי ה-SPIFFE של עומסי העבודה ששולחים בקשות ל-Actors, כמו שירות הקצה הקדמי או שירות הקצה האחורי של האפליקציה. מזהה SPIFFE מזהה עומס עבודה לפי מרחב השמות וחשבון השירות של Kubernetes שבו פועלים ה-Pods שלו. לדוגמה, לפודים שפועלים במרחב השמות shop בתור חשבון השירות frontend יש את מזהה ה-SPIFFE‏ spiffe://cluster.local/ns/shop/sa/frontend. מכיוון שהמזהה תלוי רק במרחב השמות ובחשבון השירות, אתם יכולים להזין מזהים של לקוחות שעדיין לא פרסתם. אם אתם מזינים כמה מספרים, צריך להפריד ביניהם באמצעות פסיקים. הבקשות מגיעות ל-Actors דרך נתב Ingress, שמאפשר רק ללקוחות שמציגים אישור Pod עם מזהה SPIFFE שנמצא ברשימה הזו. כל לקוח ברשימה יכול להגיע לכל Actor. אם כוללים את הדגל --demo, תוכנית ההתקנה מאפשרת רק את ה-Pods של הדגמת המונה במקום לבקש מזהים. כדי להוסיף לקוחות אחרי ההתקנה, עיינו בקטע Reaching actors through the ingress router בקובץ ה-README של substrate-gke.

מה המתקין עושה

מנהל ההתקנה מפעיל את התוכנות הבאות בשמכם:

  • ‫setup-gcp: יוצר או מאמת את המשאבים הנדרשים של Google Cloud , מפעיל ממשקי API, יוצר את אשכול GKE (אם בחרתם לא להשתמש באשכול קיים) ואת הקטגוריה של Cloud Storage, ומגדיר את מדיניות ה-IAM.
  • ‫ate-setup: פריסת Agent Substrate ב-GKE, קובצי אימג' של קונטיינרים ובקרים באשכול GKE.

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

  1. מפעילה את ממשקי ה-API שנדרשים ל-Agent Substrate ב-GKE. Google Cloud
  2. יוצר אשכול GKE Standard (אם לא משתמשים באשכול קיים) שמריץ את גרסה 1.37 ואילך, עם ההגדרות הבאות:
    • איחוד זהויות של עומסי עבודה ל-GKE: מאפשר ל-Agent Substrate ב-GKE לגשת ל-Cloud Storage בלי לאחסן מפתחות בצמתים.
    • ‫GKE Dataplane V2: מטפל ברשת שנדרשת כדי לנתב בקשות נכנסות לסוכנים.
    • ‫Managed OpenTelemetry: אוסף מדדים ומעקבים מהאשכול.
  3. יוצר את הקטגוריות של Cloud Storage שמשמשות את Agent Substrate ב-GKE: אחת לתמונות המצב ואחת לקבצים שנדרשים לסביבת זמן הריצה של microVM. השם של הקטגוריה השנייה הוא השם של קטגוריית קובץ ה-snapshot, בתוספת הסיומת -assets.
  4. יוצר מאגר ב-Artifact Registry בשם ate-images בשביל קובצי האימג' של הקונטיינרים שנוצרו על ידי תוכנת ההתקנה.
  5. יוצרת חשבון שירות בשם ate-snapshot-transfer שמשמש את Agent Substrate ב-GKE להעברת קובצי snapshot.
  6. נותנים לצומתי GKE, לרכיבי Agent Substrate ב-GKE ולחשבון השירות ate-snapshot-transfer את ההרשאות ב-IAM שנדרשות כדי לגשת לקטגוריות ולקובצי האימג' של הקונטיינרים.
  7. יוצר לוחות בקרה של Cloud Monitoring שמציגים בתרשים את זמן האחזור של הניתוב, גודל קובץ ה-Snapshot ותנועת ה-gRPC של Agent Substrate ב-GKE.

לאחר מכן, תוכנית ההתקנה מבצעת את השינויים הבאים באשכול:

  1. הוספת המשאבים המותאמים אישית של Agent Substrate ב-GKE Kubernetes לאשכול, כמו WorkerPool (שמגדיר כמה ארגזי חול לא פעילים נשארים מוכנים) ו-SandboxConfig (שמגדיר זמן ריצה של ארגז חול). משאבים אחרים של Agent Substrate ב-GKE, כמו ActorTemplate (שמגדיר את קובצי האימג' של הקונטיינרים ואת המשאבים שהסוכנים משתמשים בהם) ו-Actors, הם לא משאבים ב-Kubernetes. אתם מנהלים אותם דרך Agent Substrate ב-GKE API באמצעות הפלאגין kubectl ate, פלאגין של kubectl לניהול שחקנים ו-Workers. כדי להתקין את הפלאגין, קראו את המאמר התקנת הפלאגין של kubectl ate.
  2. מגדירה את רשויות האישורים שמנפיקות את האישורים שמזהים את Agent Substrate ברכיבי GKE וב-Actors. הרכיבים מציגים את האישורים האלה כדי לאמת זה את זה באמצעות mTLS.
  3. פריסת רכיבי Agent Substrate ב-GKE באשכול, יחד עם מסד נתונים של PostgreSQL שעוקב אחרי המצב של ה-Actors וה-Workers. מסד הנתונים מאחסן את הנתונים שלו בדיסק אחסון מתמיד (persistent disk) בנפח 500GiB. תוכנת ההתקנה ממתינה עד שמסד הנתונים וכל ה-Pods של מישור הבקרה יהיו מוכנים. באשכולות בסביבת הייצור, אתם יכולים לבודד את מסד הנתונים של PostgreSQL ואת רכיבי התשתית של המערכת למאגרי צמתים ייעודיים לפני הפעלת תוכנת ההתקנה. הוראות מפורטות זמינות במאמר בידוד של תשתית המערכת ומאגרי צומתי העובדים.

‫Agent Substrate ב-GKE פורס את הרכיבים שלו כעומסי עבודה רגילים במרחבי השמות ate-system ו-podcertificate-controller-system. אם מתקינים באשכול קיים, תוכנית ההתקנה גם מעדכנת את האשכול כדי להפעיל את התכונות הבאות אם הן מושבתות: איחוד זהויות של עומסי עבודה ל-GKE,‏ Managed OpenTelemetry וגרסאות הבטא של ממשקי ה-API של podcertificaterequests ו-clustertrustbundles ב-Kubernetes. הפעלת ממשקי ה-API בגרסת בטא מעדכנת את מישור הבקרה של GKE, וזה לוקח בערך 10 דקות.

הרכיבים שנפרסים כוללים את סביבת זמן הריצה שמבוססת על gVisor, שמשמשת את Agent Substrate ב-GKE כברירת מחדל כדי לבודד כל אחד מהסוכנים מהצומת שבו הוא פועל. אם בוחרים בסביבת זמן הריצה של microVM במהלך השלבים האופציונליים, תוכנית ההתקנה גם מעלה ל-Cloud Storage את הקבצים שסביבת זמן הריצה של microVM צריכה, ומחילה משאב SandboxConfig ברמת האשכול בשם microvm שמפנה לקבצים האלה.

כדי להשתמש בסביבת זמן הריצה של microVM, צריך צמתים שיכולים להריץ מכונות וירטואליות. כשמנהל ההתקנה יוצר אשכול, מאגר הצמתים שהוא יוצר כולל וירטואליזציה בתצורה מקוננת. אם בוחרים בהגדרה Advanced ומשנים את סוג המכונה, צריך לבחור סדרת מכונות שתומכת בווירטואליזציה בתצורה מקוננת, כמו C3,‏ C4,‏ N2 או N4.

אם מתקינים את Agent Substrate ב-GKE באשכול קיים, מנהל ההתקנה לא מוסיף מאגרי צמתים לאשכול. כדי להשתמש בסביבת זמן הריצה של microVM, צריך מאגר צמתים באשכול שהופעלה בו וירטואליזציה בתצורה מקוננת, או שמשתמש במכונה פיזית מסוג x86. אפשר להפעיל וירטואליזציה בתצורה מקוננת רק כשיוצרים מאגר צמתים. אם באשכול אין מאגר צמתים כזה, תופיע אזהרה של תוכנת ההתקנה כשתבחרו בסביבת זמן הריצה של microVM. אם ממשיכים, ה-microVM Workers נשארים במצב Pending. למידע נוסף על הגדרת מאגרי הצמתים האלה, כולל taints, ראו סביבות זמן ריצה של ארגז חול בקובץ README של substrate-gke.

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

כדי לשדרג התקנה קיימת של Agent Substrate ב-GKE, מריצים את תוכנת ההתקנה ובוחרים באפשרות Upgrade an installed cluster. האפשרות הזו לא משנה את האשכול. במקום זאת, תוכנית ההתקנה מורידה את קוד המקור של הגרסה המותקנת ושל הגרסה שאליה משדרגים, ומכינה את הספרייה ~/ate-upgrade שבה משתמש מדריך ההפעלה לשדרוג. כדי לבצע את השדרוג, מריצים את הפקודה שמופיעה במתקין, ואז פועלים לפי מדריך ההפעלה לשדרוג במאגר Agent Substrate במעלה הזרם מהשלב הראשון. מדריך ההפעלה תומך בשדרוגים לגרסת תיקון מאוחרת יותר של אותה גרסה משנית, ובגרסה 1.0 ואילך, לגרסה המשנית הבאה. בגרסאות שקודמות ל-1.0, כדי לעבור לגרסה משנית מאוחרת יותר צריך להתקין מחדש. פרטים נוספים זמינים בקטע Upgrading an installed cluster בקובץ README של substrate-gke.

שלבים אופציונליים

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

  • מנהל התקן CSI של Filestore: מתקין את מנהל התקן CSI של Filestore שמוגדר ל-Agent Substrate ב-GKE. האפשרות הזו מתאימה אם הסוכנים שלכם צריכים אחסון מתמיד שזמין כשהסוכן ממשיך לפעול בצומת אחר. לכל סוכן יש נפח אחסון משלו, שלא משותף עם סוכנים אחרים. התמיכה ב-Production בנפחי אחסון לסוכנים ב-Filestore היא ב-GA מוגבל, ולכן צריך לבקש גישה. פרטים נוספים זמינים במאמר שימוש בנפחי אחסון לסוכנים ב-Filestore עם Agent Substrate ב-GKE. אם ב-cluster מופעל התוסף המנוהל של GKE Filestore, תוכנת ההתקנה משביתה אותו לפני פריסת הדרייבר. ההתקנה פורסת את מנהל ההתקן במרחב השמות gcp-filestore-csi-driver ויוצרת חשבון שירות בשם substrate-filestore-csi, עם הרשאות ה-IAM שמנהל ההתקן צריך.
  • התאמה אוטומטית לעומס של מאגר צמתים: מאפשרת התאמה אוטומטית לעומס של אשכול GKE במאגר הצמתים. מציינים את המספר המינימלי והמקסימלי של הצמתים במאגר. בחרו באפשרות הזו אם אתם רוצים ש-GKE יוסיף צמתים באופן אוטומטי בזמן עומס, ויסיר צמתים כשהסוכנים מושעים. אם אתם מעדיפים מספר קבוע של צמתים עם עלויות מחשוב צפויות, דלגו על האפשרות הזו. במאמר תכנון התשתית ל-Agent Substrate ב-GKE מוסבר איך להגדיר חלופת חומרה אוטומטית עם ComputeClasses בהתאמה אישית, מאגרים זמניים למשאבי מחשוב במצב המתנה והגנות מפני צמצום אנכית בהתאם לעומס (scale down) של סוכנים פעילים.
  • זמן ריצה בארגז חול (Sandbox): מאפשר לבחור את זמן הריצה שמבודד את הסוכנים. מנהל ההתקנה מתקין את סביבת זמן הריצה של gVisor כחלק מרכיבי הליבה, כך שאין צורך בהגדרה נוספת של סביבת זמן הריצה של gVisor. אם אתם רוצים בידוד שמשתמש בווירטואליזציה של חומרה, בחרו בסביבת זמן הריצה של microVM. לפני שבוחרים באפשרות הזו לאשכול קיים, צריך לוודא שבאשכול יש מאגר צמתים שמופעלת בו וירטואליזציה בתצורה מקוננת, או שמשתמש במכונה פיזית מסוג x86. לפרטים נוספים, ראו מה עושה תוכנית ההתקנה.
  • הדגמה של מונה: פריסה של עומס עבודה לדוגמה שמדגים השעיה ושחזור של סוכן. השלב הזה מופיע רק אם כוללים את הדגל --demo כשמפעילים את תוכנית ההתקנה. בוחרים באפשרות הזו אם רוצים לבדוק את האשכול אחרי ההתקנה. פרטים נוספים זמינים במאמר הדגמה של Counter.

אימות ההתקנה

כדי לוודא שההתקנה הצליחה ושרכיבי הליבה פועלים, מריצים את הפקודות הבאות ומוודאים שהסטטוס של כל ה-Pods הוא Running:

kubectl get pods -n ate-system
kubectl get pods -n podcertificate-controller-system

התקנת הפלאגין kubectl ate

כדי לנהל את המשאבים של Actors ו-ActorTemplate, מתקינים את הפלאגין kubectl ate מקוד המקור של גרסת Agent Substrate שהתקנתם:

git clone --depth 1 --branch VERSION https://github.com/agent-substrate/substrate.git
cd substrate
go install ./cmd/kubectl-ate

מחליפים את VERSION בגרסת Agent Substrate שהתקנתם, למשל v1.0.0, גרסת ברירת המחדל של תוכנת ההתקנה.

הפקודה go install ממקמת את הפלאגין בספרייה bin של סביבת העבודה ב-Go. הכלי kubectl מוצא את הפלאגין רק אם הספרייה הזו נמצאת במשתנה הסביבה PATH. אם משתנה הסביבה PATH לא כולל את הספרייה הזו, צריך להוסיף אותה לפני שמריצים פקודות kubectl ate:

export PATH="$PATH:$(go env GOPATH)/bin"

הדגמה של Counter

אם כללתם את הדגל --demo כשהפעלתם את תוכנת ההתקנה ובחרתם לפרוס את הדמו של Counter, תוכנת ההתקנה פורסת WorkerPool ו-ActorTemplate לשרת אינטרנט שסופר בקשות בזיכרון ובקובץ. ‫Agent Substrate ב-GKE שומר את שני המספרים כשאתם משעים ומשחזרים את ה-Actor שמפעיל את השרת.

בסיום ההתקנה, מנהל ההתקנה מדפיס את השלבים הבאים של ההדגמה: פקודה שמתקינה את הפלאגין kubectl ate ופקודה שיוצרת Actor מ-ActorTemplate. לפני שמריצים פקודות של kubectl ate, צריך לוודא שהפלאגין נמצא במשתנה הסביבה PATH, כמו שמתואר בקטע התקנת הפלאגין של kubectl ate.

מנהל ההתקנה לא מדפיס פקודה ששולחת בקשות ל-Actor. נתב ה-Ingress מקבל רק לקוחות שמציגים אישור Pod שמזהה ה-SPIFFE שלו נמצא ברשימת ההיתרים שלו, ולכן הוא דוחה בקשות שנשלחות ישירות מהמכונה המקומית. למידע נוסף על ההדגמה, קראו את קובץ ה-README של Counter demo לגרסה 1.0.0 של Agent Substrate, שתוכנת ההתקנה פורסת כברירת מחדל. באשכול שהוגדר על ידי תוכנת ההתקנה, השלבים בקובץ README ששולחים בקשות דרך העברה ליציאה אחרת לא פועלים, מאותה סיבה.

הסרת Agent Substrate ב-GKE

בסיום ההתקנה והיציאה, תוכנית ההתקנה מדפיסה פקודות ניקוי בהתאמה אישית לסביבה שלכם.

כדי להסיר משאבים שנוצרו במהלך ההתקנה, בוחרים אחת מהאפשרויות הבאות:

  • הסרת Agent Substrate ב-GKE מאשכול קיים: אם התקנתם באשכול קיים ואתם רוצים לשמור את האשכול ואת עומסי העבודה האחרים שלו, אתם יכולים למחוק רק את הרכיבים של Agent Substrate ב-GKE. כדי לעשות את זה, מריצים את הפקודה ate-setup delete ate-system שמדפיס מנהל ההתקנה. מנהל ההתקנה מאכלס מראש את הפקודה הזו בערכים של הפרויקט, האשכול והמיקום שהוגדרו במהלך ההתקנה.

  • מחיקת כל המשאבים (כולל האשכול): כדי למחוק את אשכול GKE, את קטגוריות תמונת המצב והנכסים, את חשבון השירות ate-snapshot-transfer, את קישורי IAM, את מרכזי הבקרה ואת מאגר Artifact Registry של ate-images, מריצים את הפקודה cleanup-gcp שמדפיס תוכנית ההתקנה. מנהל ההתקנה מאכלס שדות מראש את הפקודה הזו בערכים של הפרויקט, האשכול, המיקום והקטגוריה שהוגדרו במהלך ההתקנה. הפקודה מריצה את הסקריפט tools/cleanup-gcp באמצעות נתיב יחסי, לכן צריך להריץ את הפקודה מהספרייה שבה תוכנת ההתקנה שכפלה את המאגר substrate-gke. כברירת מחדל, מנהל ההתקנה משכפל את המאגר לספרייה ~/.substrate-gke.

    אם באשכולות אחרים בפרויקט פועל Agent Substrate ב-GKE, מוסיפים לפקודה את הדגל --cluster-scoped. הדגל הזה שומר על מרכזי הבקרה, על חשבון השירות של ate-snapshot-transfer ועל הקישורים של IAM ברמת הפרויקט, שמשותפים לאשכולות האלה. הדגל --cluster-scoped לא שומר את המאגר ate-images. אם אשכולות אחרים באותו אזור משתמשים במאגר ate-images, צריך להוסיף גם את הדגל --keep-repository בסוף הפקודה. לפרטים, ראו את הקטע Tearing down בקובץ substrate-gke README.

הפקודה cleanup-gcp לא מוחקת את המשאבים הבאים:

  • הדיסק לאחסון מתמיד של מסד הנתונים PostgreSQL: ‏GKE שומר את הדיסקים לאחסון מתמיד כשהוא מוחק אשכול, ולכן אתם ממשיכים לשלם על הדיסק בנפח 500GiB. כדי למחוק את הדיסק, מריצים את הפקודה ate-setup delete ate-system שמוצגת על ידי תוכנת ההתקנה. לאחר מכן, ממתינים עד שהפקודה kubectl get pv לא תציג יותר נפח לבקשה ate-system/data-postgres-0, לפני שמריצים את cleanup-gcp. אם כבר מחקתם את האשכול, אתרו את הדיסק באמצעות הפקודה הבאה ואז מחקו אותו באמצעות הפקודה gcloud compute disks delete:

    gcloud compute disks list --filter="description~data-postgres-0"

  • חשבון השירות substrate-filestore-csi: כל האשכולות בפרויקט שמריצים את מנהל ההתקן של Filestore CSI משתפים את חשבון השירות הזה. אם התקנתם את מנהל ההתקן ואין אשכולות אחרים בפרויקט שמריצים אותו, אתם יכולים למחוק את חשבון השירות באמצעות הפקודה הבאה:

    gcloud iam service-accounts delete substrate-filestore-csi@PROJECT_ID.

    מחליפים את PROJECT_ID במזהה הפרויקט.

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