בסביבת multi-cluster Google Kubernetes Engine (GKE) Inference Gateway, אפשר להחיל הגדרות שונות של קצה עורפי על שירותים שנפרסו בכמה אשכולות. לדוגמה, אפשר להגדיר שיעורי בקשות מקסימליים שונים או משני קיבולת שונים לעורפי קצה באזורים או בסביבות שונים.
כדי להבין את המאמר הזה, צריך להכיר את המושגים הבאים:
- תזמור של AI/ML ב-GKE.
- טרמינולוגיה של AI גנרטיבי.
- מושגים בנושא רישות ב-GKE, כולל Services, GKE Multi Cluster Ingress ו- GKE Gateway API.
- איזון עומסים ב-Cloud de Confiance, ובמיוחד איך מאזני עומסים פועלים עם GKE.
המסמך הזה מיועד לדמויות הבאות:
- מהנדסי למידת מכונה (ML), אדמינים ומפעילים של פלטפורמות ומומחים לנתונים ול-AI שמעוניינים להשתמש ביכולות של Kubernetes לארגון קונטיינרים כדי להפעיל עומסי עבודה של AI/ML.
- מומחי Cloud Architect או מומחי רשתות שיוצרים אינטראקציה עם רשתות Kubernetes.
במאמר תפקידי משתמשים נפוצים ומשימות לדוגמה ב-GKE Enterprise מוסבר על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בCloud de Confiance by S3NS תוכן.
איך היקפי ההרשאות של GCPBackendPolicy פועלים
השדה scopes ב-GCPBackendPolicy מאפשר לכם להתאים אישית את ההגדרות של הקצה העורפי בהתאם לאשכולות הספציפיים שבהם הקצה העורפי פועל. אתם יכולים להחיל הגדרות שונות על שרתים עורפיים בסביבות או באזורים שונים, וכך לקבל שליטה מדויקת על עומסי העבודה המבוזרים של AI/ML. בקטעים הבאים מוסבר איך לטרגט משאבים, להגדיר היקפי מדיניות ולטפל בפתרון קונפליקטים.
משאבים של שער ההסקה
כדי להשתמש במדיניות של Inference Gateway בסביבת GKE מרובת אשכולות, השדה GCPBackendPolicy של targetRef צריך להפנות למשאב GCPInferencePoolImport:
targetRef:
group: networking.gke.io
kind: GCPInferencePoolImport
name: example
הגדרת היקף המדיניות
בשדה scopes ב-GCPBackendPolicy אפשר להחיל הגדרות שונות של קצה עורפי על קבוצות ספציפיות של קצה עורפי. אפשר להגדיר אובייקטים של הגדרות בתוך default.scopes כדי להשתמש בתוויות של אשכולות לטירגוט מדויק של שרתים עורפיים ולהחיל הגדרות ספציפיות. לדוגמה, אפשר להגדיר מגבלות קיבולת ייחודיות או שיעורי בקשות שונים לשרתי קצה עורפיים באזורים או באשכולות שונים.
אי אפשר לציין את אותם שדות ברמת ה-Backend (כמו maxRatePerEndpoint) גם בקטע הראשי default וגם בערכים default.scopes.
ניסיון לעשות זאת יגרום לדחיית המדיניות, וכך יתאפשר להבטיח הגדרות ברורות ועקביות.
יישוב סכסוכים
כדי להבטיח התנהגות צפויה, אם קצה עורפי תואם לכמה היקפי הרשאות, המערכת תחיל את הכללים הבאים:
- התאמה לפי סדר עדיפויות: אם קצה עורפי מתאים לכמה סלקטורים ברשימת
scopes, המערכת מחילה רק את ההגדרות מהסלקטור הראשון שתואם. כדי לוודא שההגדרה הרצויה תיכנס לתוקף, כדאי לסדר את ההיקפים מהספציפי ביותר לכללי ביותר. - טירגוט מדויק: אם בבורר יחיד יש כמה תוויות (לדוגמה,
gke.io/region: us-central1ו-env: prod), המערכת תחיל את ההגדרה של היקף הבורר רק אם ה-backend יקיים את כל התוויות האלה. הגישה הזו מאפשרת לכם לטרגט במדויק את השרתים העורפיים על סמך קריטריונים רבים.
שדות נתמכים לכל קצה עורפי
בטבלה הבאה מפורטים השדות ברמת ה-Backend שאפשר להתאים אישית כדי לשלוט בהתנהגות ה-Backend בסביבות או באזורים שונים.
| שם השדה | תיאור | הגדרה לדוגמה |
|---|---|---|
backendPreference |
מציין אם העורף המקודד מועדף (PREFERRED) או ברירת מחדל (DEFAULT) במהלך מעקב אחרי קיבולת לאיזון עומסים במספר אזורים. |
backendPreference: PREFERRED |
balancingMode |
מציין את אלגוריתם האיזון. הערכים הנתמכים הם RATE, UTILIZATION או CUSTOM_METRICS. |
balancingMode: CUSTOM_METRICS |
capacityScalerPercent |
הגדרת חלוקת התנועה על סמך הקיבולת. הערך הזה הוא אחוז בין 0 ל-100, שמשמש כמכפיל של קיבולת היעד שהוגדרה בקצה העורפי. ערך ברירת המחדל הוא 100%. | capacityScalerPercent: 20 |
customMetrics |
מציין מדדים מותאמים אישית שמשמשים לאיזון עומסים כשמגדירים את balancingMode לערך CUSTOM_METRICS. השדה הזה
הוא רשימה של הגדרות מדדים. |
customMetrics: [{ name: "my-metric", value: 0.8 }] |
maxInFlightPerEndpoint |
ההגדרה הזו קובעת את המספר המקסימלי של בקשות או חיבורים בו-זמניים לכל נקודת קצה. | maxInFlightPerEndpoint: 100 |
maxRatePerEndpoint |
הגדרת קצב הבקשות המקסימלי לכל נקודת קצה, בבקשות לשנייה (RPS). | maxRatePerEndpoint: 50 |
ציון בוררי היקף
השדה selectors בכל היקף מאפשר לכם לקבוע אילו שרתים עורפיים יקבלו הגדרות מדיניות ספציפיות. אתם יכולים לטרגט קצה עורפי על סמך תוויות האשכול שלו – תוויות GKE מובנות או תוויות מותאמות אישית משלכם – כדי להתאים אישית את ההגדרות לקבוצות שונות של קצה עורפי.
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: echoserver-v2
spec:
targetRef:
group: "networking.gke.io"
kind: GCPInferencePoolImport
name: test-inference-pool
default:
balancingMode: IN_FLIGHT # IN_FLIGHT mode is set at the default level
scopes:
- selector:
gke.io/zone: "us-central1-a"
maxInFlightPerEndpoint: 100 # Invalid: maxInFlightPerEndpoint cannot be set within a scope when balancingMode is IN_FLIGHT at the default level
תוויות GKE מרומזות
אפשר להשתמש בתוויות המשתמעות הבאות כסלקטורים. מערכת GKE מחילה את התוויות האלה על האשכולות שלכם באופן אוטומטי:
| תווית | תיאור | ערך לדוגמה |
|---|---|---|
gke.io/cluster-name |
השם של אשכול GKE. | my-cluster |
gke.io/region |
האזור שבו נמצא האשכול. | us-central1 |
gke.io/zone |
האזור שבו נמצא האשכול. | us-central1-a |
תוויות מותאמות אישית של אשכולות
תוויות מותאמות אישית של אשכולות מספקות יותר גמישות בקיבוץ ובניהול של שרתי הקצה העורפיים. אם מגדירים תוויות משלכם באשכולות GKE, אפשר ליצור סלקטורים ספציפיים מאוד ב-GCPBackendPolicy כדי להחיל הגדרות ייחודיות. לדוגמה, אפשר לבסס את ההגדרות האלה על קריטריונים כמו סביבות שונות (dev, staging או prod) או גרסאות ספציפיות של אפליקציות.
כדי להוסיף תווית בהתאמה אישית, כמו environment=production, לאשכול GKE, מריצים את הפקודה הבאה:
gcloud container clusters update CLUSTER_NAME \
--region=REGION \
--update-labels=LABEL_KEY=LABEL_VALUE
מחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: השם של האשכול. -
REGION: האזור של האשכול. -
LABEL_KEY: המפתח של התווית המותאמת אישית, לדוגמהenvironment. -
LABEL_VALUE: הערך של התווית המותאמת אישית, לדוגמה,production.
לאחר מכן תוכלו לבחור בקצה העורפי באשכול הזה באמצעות בורר התוויות המותאם אישית במדיניות.
דוגמה ל-GCPBackendPolicy עם בוררי היקף
בדוגמה הבאה מוגדר GCPBackendPolicy שמטרגט GCPInferencePoolImport בשם experimental. המדיניות משתמשת בתוויות מרומזות ובתוויות בהתאמה אישית כדי להגדיר ערכים ל-backendPreference, ל-maxRatePerEndpoint ול-capacityScalerPercent.
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: backend-policy
spec:
targetRef:
kind: GCPInferencePoolImport
name: experimental
default:
scopes:
# Selector 1: Targets backends in us-west2, sets capacity to 50%
- capacityScalarPercent: 50
selector:
gke.io/region: us-west2
# Selector 2: Targets backends in clusters labeled 'env: prod'
- maxRatePerEndpoint: 40
selector:
env: prod
# Selector 3: Targets backends in a specific US-Central zone and marks them as PREFERRED
- backendPreference: PREFERRED
maxRatePerEndpoint: 50
selector:
gke.io/cluster-name: my-cluster
gke.io/zone: us-central1-a
אחרי שמחילים את המדיניות הזו, אפשר לראות את ההתנהגויות הבאות:
- הקיבולת האפקטיבית של שרתים עורפיים באשכולות באזור
us-west2תוגדל ל-50%. - בשרתי קצה עורפיים באשכולות שמסומנים בתווית
env: prod, יש מגבלה של 40 בקשות לשנייה לכל נקודת קצה. - לשרתי קצה עורפי באשכולות שממוקמים באזור
us-central1-aיש עדיפות (PREFERRED) במהלך איזון העומסים, והקצב המקסימלי שלהם הוא 50 בקשות לשנייה לכל נקודת קצה.
המאמרים הבאים
- איך מגדירים
GCPBackendPolicy - מידע נוסף על GKE Inference Gateway עם כמה אשכולות
- מידע נוסף על הגדרת שער ההסקה של GKE עם כמה אשכולות