מגבלות שינוי הגודל של Cloud Service Mesh ב-GKE

במסמך הזה מתוארות מגבלות ההרחבה של מישור הבקרה לארכיטקטורות מנוהלות של Cloud Service Mesh ב-GKE, כדי שתוכלו לקבל החלטות מושכלות לגבי הפריסות שלכם.

סקירה כללית

היכולת של Cloud Service Mesh להתרחב ב-GKE תלויה בפעולה היעילה של שני הרכיבים העיקריים שלו: מישור הנתונים ומישור הבקרה. המאמר הזה מתמקד במגבלות ההרחבה של מישור הבקרה. מידע על שיטות מומלצות להרחבת מישור הנתונים זמין במאמר בנושא שיטות מומלצות להרחבת יכולות.

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

כדי להבין איך משאבי Istio מתורגמים למשאבי Google Cloud , כדאי קודם לעיין במדריך הסבר על משאבי API.

הערה: המגבלות שמתועדות במדריך הזה רלוונטיות רק לTRAFFIC_DIRECTORהטמעה של מישור הבקרה.

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

מגבלות על שינוי גודל השירות

ההתאמה של השירות מוגבלת בשני מימדים

• לכל פרויקט: יש תמיכה בעד 5,000 שירותים של Cloud Service Mesh לכלGoogle Cloud פרויקט (למעט שירותים ללא כתובת IP ב-Kubernetes).

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

שימו לב: אחרי שמפעילים את Cloud Service Mesh לחברות מסוימת (כלומר, לאשכול GKE), כל שירותי Kubernetes באשכול מתורגמים לשירותי Cloud Service Mesh, כולל אלה שמיועדים לעומסי עבודה ללא Cloud Service Mesh sidecar. ‫Cloud Service Mesh יוצר קבוצות של נקודות קצה ברשת אזורית לכל השירותים באשכול GKE. אם האשכול הוא אזורי, המערכת יוצרת קבוצות של נקודות קצה ברשת לכל האזורים במאגר הצמתים באזור.

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

שירותי Cloud Service Mesh לעומת שירותי Kubernetes

שירותי Cloud Service Mesh לא זהים לשירותי Kubernetes, כי כל שירות ב-Cloud Service Mesh הוא שירות אחד לכל יציאה.

לדוגמה, שירות Kubernetes הזה מתורגם באופן פנימי לשני שירותים של Cloud Service Mesh, אחד לכל יציאה.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

אפשר לעקוב אחרי השימוש בשירות Cloud Service Mesh על ידי בדיקת השימוש במכסת BackendService בפרויקט.

פריסות מרובות אשכולות

כשפורסים רשת אחת על פני עומסי עבודה באשכולות שונים Google Cloud, כל משאבי השירות של Cloud Service Mesh משוכפלים כברירת מחדל בכל האשכולות. כלומר, שירות Kubernetes שנפרס באשכול יחיד יוצר כמה שירותים של Cloud Service Mesh, אחד לכל אשכול.

קבוצות משנה של כללי יעד

כשמגדירים את Istio Destination Rule API עם קבוצות משנה, כל קבוצת משנה עשויה להוביל ליצירה של כמה שירותים חדשים של Cloud Service Mesh.

לדוגמה, נניח שיש לנו את DestinationRule הבא שמכוון לשירות Kubernetes שהוגדר קודם:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

ייווצרו שירותים סינתטיים חדשים לכל אחת מקבוצות המשנה שהוגדרו. אם שירות Kubernetes המקורי יצר שני שירותים של Cloud Service Mesh, הפקודה DestinationRule תיצור 4 שירותים נוספים של Cloud Service Mesh, ‏ 2 לכל קבוצת משנה, כך שיהיו בסך הכול 6 שירותים של Cloud Service Mesh.

פריסות של כמה פרויקטים

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

שירותים ללא כתובת IP ב-Kubernetes

ההגבלה על שירותים ללא כתובת IP ב-Kubernetes נמוכה יותר בהשוואה לשירותים רגילים. ב-Cloud Service Mesh יש תמיכה רק ב-50 שירותים של Cloud Service Mesh ללא ממשק משתמש לכל אשכול. דוגמה מופיעה במסמכי התיעוד בנושא רשתות Kubernetes.

מקורות מידע על Istio Sidecar

המגבלות הבאות חלות על Istio Sidecar API:

• ‫Sidecar בלי workloadSelector: 150 לכל אשכול

• ‫Sidecar עם workloadSelector: ‏ 20 לכל אשכול

מגבלות על שינוי הגודל של נקודות קצה

בדרך כלל, מגבלות ההרחבה של נקודות הקצה הן לפי:

• שירות Cloud Service Mesh

• אשכול GKE

שירותי Kubernetes רגילים

מכסות של נקודות קצה לכל NEG משפיעות על המספר המקסימלי של נקודות קצה שיכולות להיות שייכות לשירות Kubernetes יחיד.

שירותים ללא כתובת IP ב-Kubernetes

בשירות Kubernetes headless, ‏ Cloud Service Mesh תומך ב-36 נקודות קצה לכל היותר לכל שירות headless. דוגמה מופיעה במסמכי התיעוד בנושא רשתות ב-Kubernetes.

מגבלות על אשכולות GKE

‫Cloud Service Mesh תומך בעד 20,000 נקודות קצה (כתובות IP של Pods, מופעים של Cloud Run, לקוחות gRPC בלי שרת Proxy) לכל פרויקט.

מגבלת קנה מידה של שער

כשמשתמשים ב-Istio Gateways, במיוחד כדי לסיים חיבורי HTTPS באמצעות אישורי TLS ב-Kubernetes secrets,‏ Cloud Service Mesh תומך במספר הפודים הבא לכל היותר:

• ‫1,500 gateway pods כשמשתמשים באשכולות GKE אזוריים

• ‫500 פודים של שערים כשמשתמשים באשכולות GKE אזוריים או באשכולות GKE Autopilot