הגדרת קישוריות מ-Agent Platform לרשתות אחרות

במסמך הזה נתחיל בתיאור האפשרויות להרחבת הטווח של שירותי Agent Platform שנפרסו באמצעות גישה לשירותים פרטיים.

לאחר מכן נדון בקצרה בסיבות לפריסת השירותים בנקודת קצה (endpoint) של Private Service Connect, אם היא מתאימה יותר לצרכים שלכם.

מכיוון שהגישה לשירותים פרטיים מארחת את שירותי Agent Platform ברשת מנוהלת שמקושרת לרשת שלכם, חשוב שתכירו את החומר בנושא קישורי VPC לפני שתקראו את שאר המסמך הזה.

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

בגלל שאין תמיכה בקישור טרנזיטיבי בין רשתות שכנות (transitive peering), החיבורים מפלטפורמת הסוכנים לא יכולים להגיע לנקודות קצה ברשתות אחרות שמקושרות ישירות לרשת שלכם, גם אם הפעלתם את האפשרות Export custom routes. בדוגמה שמוצגת בתרשים הבא, חבילות יכולות לעבור דרך חיבור Peering מספר 1, אבל לא דרך חיבור Peering מספר 2.

עם קישור מעבר בין רשתות שכנות (peering)

כדי לאפשר ל-Agent Platform להגיע ל-User Network #2, מחליפים את Peering Connection #2 ב-VPN #2, כמו שמוצג בתרשים הבא.

בלי קישור מעבר בין רשתות שכנות (peering)

הפעלת נתיבים בהתאמה אישית בחיבור בין רשתות שכנות (peering) מס' 1 מאפשרת לחבילות IP מרשת Agent Platform להגיע לרשת משתמש מס' 2.

כדי לאפשר ניתוב של חבילות תגובה מרשת משתמש 2 בחזרה לרשת Agent Platform, צריך שגם בטבלת הניתוב של רשת משתמש 2 יהיה נתיב חזרה. החלפת נתיבי ה-VPN מתבצעת באמצעות Border Gateway Protocol ‏(BGP) ב-Cloud Routers. אנחנו יכולים להתאים אישית את הגדרת ה-BGP במשתמש מס' 1 כדי לפרסם נתיב לטווח הרשת של פלטפורמת הנציג (10.1.0.0/16) לרשת המשתמשים המקבילה מס' 2.

שימו לב שאתם יכולים לערוך את שני הצדדים של הגדרת ה-BGP של VPN #1, כדי לאפשר לרשת המקומית ולרשת של Agent Platform ללמוד נתיבים זו לזו. מכיוון שאין ניסיון להעביר חבילות בנתיב העברה מרשת Agent Platform, וגם לא את חבילות התגובה דרך חיבורי Peering עוקבים ביחס לרשת אחת, אף אחד מניסיונות ההעברה האלה לא נחסם באופן מפורש.

הגדרת הקישוריות מ-Agent Platform לאינטרנט

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

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

כברירת מחדל, לרשת Agent Platform יש נתיב משלה לאינטרנט, ולרשת של היצרן יש נתיב משלה לאינטרנט.

כדי לאלץ חיבורים יוצאים מרשת היצרן לעבור דרך הרשת שלכם, אתם יכולים להפעיל את VPC Service Controls לקישורים לרשתות שכנות (peering). שימו לב שזו הגדרה נפרדת מ-VPC Service Controls.

כשמפעילים את VPC Service Controls לקישורי peering, מתרחשים השינויים הבאים ברשת של Agent Platform:

  • מחיקת המסלול שמוגדר כברירת מחדל לאינטרנט.
  • יצירת מסלול ליעד 199.36.153.4/30 עם שער ברירת המחדל לאינטרנט בתור הצעד הבא.
  • יוצר תחום פרטי מנוהל ב-Cloud DNS בשביל *.googleapis.com עם רשומות מתאימות למיפוי שמות מארחים לאחת מארבע הכתובות האלה.
  • נותנת הרשאה לאזור הזה להשתמש ברשת ה-VPC של servicenetworking.

אחרי השינוי הזה, תוכלו לייצא את נתיב ברירת המחדל מהרשת שלכם כדי לוודא שהחיבורים היוצאים לאינטרנט מנותבים דרך רשת ה-VPC. השינוי הזה גם מאפשר להחיל את כללי המדיניות הנדרשים על התנועה היוצאת מ-Agent Platform.

כדי לשלוח שאילתה לגבי המצב של VPC Service Controls for Peerings, מריצים את הפקודה הבאה:

gcloud services vpc-peerings get-vpc-service-controls \
  --network YOUR_NETWORK

הפונקציה תחזיר את הערך enabled: true אם ההגדרה מופעלת, ורשימה ריקה ({}) אם היא מושבתת.

עבודה עם VPC Service Controls

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

אם כללי המדיניות האלה חוסמים תנועה יוצאת, עומס העבודה לא יוכל להגיע לאינטרנט. במקרה כזה, צריך לפעול לפי השלבים בקטע הקודם כדי לאלץ את תעבורת הנתונים היוצאת מעומס העבודה לעבור דרך מכונת NAT ברשת ה-VPC.

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

דפוס נוסף לשליטה בכתובת ה-IP היוצאת מ-Agent Platform הוא לאלץ חיבורים יוצאים מעומסי עבודה לעבור דרך שרת proxy לאינטרנט שבשליטתכם. כך אפשר גם לבדוק את החיבורים היוצאים כדי לוודא שהם עומדים בדרישות.

עם זאת, שימוש בשרת proxy של צד שלישי מאלץ את המשתמש לנהל את האישור של שרת ה-proxy כדי לטפל בתלונות על אימות. בנוסף, יכול להיות ששרתי ה-Proxy האלה לא יציעו רשימה של סטים של אלגוריתמים להצפנה (cipher suite) שחופפת למה שמצופה מערכות ה-SDK ומממשקי ה-API של Agent Platform.

ב-Cloud de Confiance by S3NS יש עכשיו שרת proxy מאובטח לאינטרנט כדי לאפשר את התבנית הזו. עכשיו אתם יכולים לפעול לפי המדריך למתחילים פריסת מכונה של Secure Web Proxy ולהתאים את עומסי העבודה לשימוש בחיבורים יוצאים. החיבורים האלה ייראו כאילו הם מגיעים מכתובת ה-IP של המקור של שרת ה-proxy.

אם ספריית KFP עדיין לא מותקנת בתמונת הרכיב, הצינור מנסה להתקין אותה לפני הרצת קוד שבו ציינתם שרת proxy.

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

Could not find a version that satisfies the requirement kfp==2.7.0

במקרים כאלה, כשאי אפשר להתקין את KFP לפני הרצת הקוד, צריך להשתמש בתמונה ש-KFP כבר מותקן בה.

אתם יכולים להוסיף את KFP לכל קובץ אימג' בסיסי ולדחוף אותו למאגר שלכם.

בדוגמה הבאה של קובץ Docker, מוסיפים את KFP לתמונת הבסיס python:3.8.

FROM python:3.8
RUN pip install kfp==2.7.0

אחר כך אפשר להגדיר את צינור עיבוד הנתונים @component כך שישתמש בתמונה הזו:

@component(base_image="$PATH_TO_YOUR_REPOSITORY:YOUR_IMAGE")

אחרי שרכיב הצינור פועל, הקוד יכול להתקין חבילות אחרות באופן חופשי על ידי מעבר דרך שרת ה-Proxy. בדוגמה הבאה מתקינים את numpy באמצעות שרת proxy בכתובת https://10.10.10.10:443.

import subprocess
subprocess.call(['pip', 'install', '--proxy', 'https://10.10.10.10:443', 'numpy'])`

הגדרת רשימות היתרים לגישה ל-API

כדי לבצע טרנזקציות בין עומסי העבודה של Gemini Enterprise Agent Platform לבין Google APIs, צריך לאפשר גישה מעומסי העבודה לטווחי ה-IP שמשמשים את Google APIs. כדי לעשות את זה, אתם יכולים להריץ את הסקריפט שסיפקנו להחזרת כתובות IP של דומיינים שמוגדרים כברירת מחדל.

מתן קישוריות היברידית באמצעות Private Service Connect

יש כמה מגבלות לפריסת שירותי Agent Platform עם גישה לשירותים פרטיים.

  • יכול להיות שתצטרכו להקצות מאגרים גדולים של כתובות IP פרטיות לכל עומס עבודה, וגם להימנע מהתנגשויות עם כתובות ה-VPC.
    • הפעלה של כמה עומסי עבודה במקביל עדיין עלולה לגרום לשגיאה RANGES_EXHAUSTED, גם אחרי הגדרה ראשונית נכונה.
  • מורכבות הפריסה של הרשת ופתרון הבעיות:
    • בגלל שאין תמיכה בקישור טרנזיטיבי בין רשתות שכנות (peering), צריך לפרוס פתרונות עקיפים מורכבים כדי לאפשר קישוריות בין רשתות שונות שמקושרות לרשת ה-VPC שלכם.
    • המצב של טבלת הניתוב בסביבת היצרן לא ברור באופן מיידי. בגלל שאין לכם גישה לפרויקט של הדייר, בדרך כלל קשה לקבוע לאילו יעדים עומס העבודה של Agent Platform יכול להגיע בפועל בלי בדיקות מקיפות.

דפוס חלופי הוא לפרוס את השירותים האלה בנקודת קצה של Private Service Connect.

  • השירות צורך כתובת IP אחת ברשת ה-VPC, וכך מאפשר לכם לשמור מרחב כתובות פרטי לשימושכם.
  • מכיוון שכתובת ה-IP של שירות Agent Platform נמצאת ברשת שלכם, קל יותר ליצור ולהריץ בדיקות קישוריות כדי להעריך את יכולת ההגעה (reachability) שלה למקומות אחרים בסביבה שלכם וממקומות אחרים בסביבה שלכם.