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

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

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

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

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

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

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

כדי לאפשר לפלטפורמת הסוכנים להגיע לרשת משתמשים מספר 2, מחליפים את חיבור ה-Peering מספר 2 ב-VPN מספר 2, כמו שמוצג בתרשים הבא.

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

הפעלת מסלולים מותאמים אישית בחיבור Peering מספר 1 מאפשרת לחבילות IP מהרשת של Agent Platform להגיע לרשת המשתמש מספר 2.

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

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

הגדרת קישוריות מפלטפורמת הסוכן לאינטרנט

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

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

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

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

הפעלת VPC Service Controls עבור קישורים בין רשתות גורמת לשינויים הבאים ברשת Agent Platform:

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

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

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

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

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

עבודה עם VPC Service Controls

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

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

הגדרת קישוריות מ-Agent Platform באמצעות שרתי proxy

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

עם זאת, שימוש בשרת proxy של צד שלישי מחייב את המשתמש לנהל את האישור של ה-proxy כדי לפתור בעיות שקשורות לאימות. בנוסף, יכול להיות ששרתי ה-proxy האלה לא יציעו רשימה של חבילות הצפנה שחופפות למה שערכות ה-SDK וממשקי ה-API של Agent Platform מצפים.

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

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

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

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

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

אפשר להוסיף KFP לכל תמונת בסיס ולדחוף אותה למאגר.

בדוגמה הבאה של קובץ Dockerfile, מוסיפים את 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 גם אחרי הגדרה ראשונית נכונה.
  • מורכבות של פריסת רשת ופתרון בעיות:
    • מכיוון שקישוריות טרנזיטיבית לא נתמכת, צריך להשתמש בפתרונות עקיפים מורכבים כדי להעניק קישוריות בין רשתות שונות שמקושרות לרשת ה-VPC.
    • המצב של טבלת הניתוב בסביבת הייצור לא ברור באופן מיידי. מכיוון שאין לכם גישה לפרויקט הדייר (tenant), לעיתים קרובות קשה לקבוע לאילו יעדים עומס עבודה (workload) של Agent Platform יכול להגיע בפועל בלי בדיקות מקיפות.

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

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