בדף הזה מוסבר על המכסות והמגבלות של Google Distributed Cloud (תוכנה בלבד) בשרת פיזי עבור Google Cloud פרויקטים, אשכולות וצמתים.
מגבלות
בקטעים הבאים מפורטות כמה מגבלות בסיסיות על האשכולות. חשוב לקחת את המגבלות האלה בחשבון כשמתכננים את האפליקציות להרצה ב-Google Distributed Cloud.
מספר מקסימלי של אשכולות משתמשים לכל אשכול אדמין
באמצעות אשכולות אדמין אפשר לנהל את מחזור החיים של אשכולות משתמשים והצמתים המשויכים שלהם. אשכולות אדמין שולטים בפעולות קריטיות באשכולות משתמשים, כמו יצירת אשכולות, איפוס אשכולות או צמתים, שדרוג אשכולות ועדכון אשכולות. המספר הכולל של הצמתים באשכול המשתמשים הוא אחד מהגורמים העיקריים שמגבילים את הביצועים והמהימנות.
על סמך בדיקות שוטפות, אשכול אדמין יכול לתמוך באופן מהימן בעד 100 אשכולות משתמשים, שכל אחד מהם מכיל 10 צמתים, כלומר בסך הכול 1,000 צמתים.
מספר הפודים המקסימלי לכל אשכול משתמשים
מומלץ להגביל את מספר הפודים לכל אשכול משתמשים ל-15,000 או פחות. לדוגמה, אם באשכול יש 200 צמתים, צריך להגביל את מספר ה-Pods לכל צומת ל-75 או פחות. באופן דומה, אם רוצים להפעיל 110 פודים לכל צומת, צריך להגביל את מספר הצמתים באשכול ל-136 או פחות. בטבלה הבאה מופיעות דוגמאות להגדרות מומלצות ולא מומלצות.
| Pods per node | צמתים לכל אשכול | טבליות לכל אשכול | תוצאה |
|---|---|---|---|
| 110 | 200 | 22,000 | יותר מדי תרמילים, לא מומלץ |
| 110 | 136 | 14,960 | במסגרת המגבלה |
| 100 | 150 | 15,000 | במסגרת המגבלה |
| 75 | 200 | 15,000 | במסגרת המגבלה |
ההמלצה לגבי המספר המקסימלי של פודים לכל אשכול משתמשים קודמת להמלצות לגבי פודים לכל צומת וצמתים לכל אשכול משתמשים שמפורטות בקטעים הבאים.
מספר הצמתים המקסימלי לכל אשכול משתמשים
אנחנו בודקים את Google Distributed Cloud כדי להריץ עומסי עבודה עם עד 500 צמתים. עם זאת, כדי להבטיח ביצועים ואמינות אופטימליים, מומלץ לא לחרוג מ-200 צמתים לכל אשכול כשמריצים עומסי עבודה בסביבת ייצור.
| סוג האשכול | מספר צמתים מינימלי | מספר הצמתים המקסימלי המומלץ | מספר הצמתים המקסימלי |
|---|---|---|---|
| משתמש, עצמאי או היברידי | 1 | 200 | 500 |
במקרים של אשכולות עם צומת יחיד, צריך להסיר את ה-taint node-role.kubernetes.io/master:NoSchedule כדי להריץ עומסי עבודה בצומת.
פרטים נוספים זמינים במאמר בנושא Kubernetes taints and tolerations.
מספר הפודים המקסימלי לכל צומת
Google Distributed Cloud תומך בהגדרה של מספר הפודים המקסימלי לכל צומת בהגדרה nodeConfig.PodDensity.MaxPodsPerNode של קובץ הגדרת האשכול. בטבלה הבאה מפורטים הערכים המינימליים והמקסימליים שנתמכים עבור MaxPodsPerNode, כולל פודים שמריצים שירותי תוספים:
| סוג האשכול | הערך המינימלי המותר | ערך מקסימלי מומלץ | הערך המקסימלי המותר |
|---|---|---|---|
| כל אשכולות ה-HA ואשכולות המשתמשים שאינם HA | 32 | 110 | 250 |
| כל שאר האשכולות שאינם HA | 64 | 110 | 250 |
מספר נקודות הקצה המקסימלי
ב-Red Hat Enterprise Linux (RHEL), יש מגבלה ברמת האשכול של 100,000 נקודות קצה. המספר הזה הוא הסכום של כל ה-Pods שמקושרים לשירות Kubernetes. אם שני שירותים מקושרים לאותה קבוצה של Pods, המצב הזה נחשב לשתי קבוצות נפרדות של נקודות קצה. המגבלה הזו נובעת מההטמעה הבסיסית ב-RHEL, ולא מהמגבלה המובנית של Google Distributed Cloud.nftable
השבתה זמנית של אותות אכיפה
ב-RHEL, אין אמצעי הגנה. במערכות Ubuntu ו-Debian, מומלץ לעבור מ-nftables שמוגדר כברירת מחדל ל-iptables מדור קודם באשכולות בקנה מידה גדול.
Dataplane V2
Google Distributed Cloud משתמש ב-Dataplane V2, מישור נתונים של אשכול שמיושם באמצעות Cilium ו-eBPF, והוא מותאם לרשתות Kubernetes.
מגבלות של Dataplane V2 NetworkPolicy
Dataplane V2 משתמש ב-Cilium כדי לנהל משאבי Kubernetes NetworkPolicy. המגבלות הבאות חלות על האשכולות שלכם:
| מאפיין | מגבלות נתמכות |
|---|---|
| שיעור השינוי המקסימלי של תוויות במרחב שמות | לכל היותר, שינוי אחד בשעה לכל מרחב שמות.
ברוב המקרים, אין צורך להגביל את מספר השינויים. כל עוד השינויים לא תכופים, למשל כל שנייה, או שמספר זהויות Cilium (קבוצות של תוויות ייחודיות) לא קרוב למגבלה: 16,000 קבוצות של תוויות עם מדיניות רשת של allow all, או 65,535 קבוצות של תוויות לכל אשכול. |
| מספר נקודות הקצה המקסימלי של שירותים לכל אשכול | המגבלה שנבדקה ומומלצת היא 100,000 נקודות קצה. המגבלה שמוגדרת מראש לנקודות קצה של שירותים היא 262,000. |
| מספר מקסימלי של כללי מדיניות וכללים ברשת | עד 40,000 כללי מדיניות לרשת ו-80,000 כללים. לדוגמה, אפשר לציין 40,000 כללי מדיניות לרשת עם שני כללים לכל אחד, או לציין 20,000 כללי מדיניות עם ארבעה כללים לכל אחד. |
| קצב השינוי המקסימלי של מדיניות הרשת | עד 20 שינויים (יצירות או מחיקות) בשנייה. |
| מספר מקסימלי של קבוצות תוויות ייחודיות של פודים | 65,535 (216-1). זוהי המגבלה של זהות האבטחה של Cilium. |
| המספר המקסימלי של קבוצות תוויות ייחודיות של פודים שנבחרו על ידי כללי בחירה של מדיניות | 16,000 (הגודל הקבוע של מפת eBPF). כל רשומה במפת בורר המדיניות מורכבת מהרכיבים הבאים: זהות אבטחה, יציאה ופרוטוקול. |
מגבלת eBPF של Dataplane V2
המספר המקסימלי של רשומות ב-BPF lbmap עבור Dataplane V2 הוא 65,536. העלייה במספר הכולל של הרשומות יכולה לנבוע מהעלייה בנתונים הבאים:
- מספר השירותים
- מספר היציאות לכל שירות
- מספר ה-backends לכל שירות
מומלץ לעקוב אחרי מספר הרשומות בפועל שמשמשות את האשכול כדי לוודא שלא חורגים מהמגבלה. משתמשים בפקודה הבאה כדי לקבל את הרשומות הנוכחיות:
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
מומלץ גם להשתמש בצינור עיבוד נתונים משלכם למעקב כדי לאסוף מדדים מ-DaemonSet anetd. כדי לזהות מתי מספר הרשומות גורם לבעיות, צריך לעקוב אחרי התנאים הבאים:
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
מגבלת היציאות בשירותי LoadBalancer ו-NodePort
מגבלת הפורטים בשירותי LoadBalancer ו-NodePort היא 2,768. טווח הפורטים שמוגדר כברירת מחדל הוא 30000-32767. אם חורגים מהמגבלה, אי אפשר ליצור שירותי LoadBalancer או NodePort חדשים, ואי אפשר להוסיף פורטים חדשים של צמתים לשירותים קיימים.
כברירת מחדל, Kubernetes מקצה יציאות צמתים לשירותים מסוג LoadBalancer. ההקצאות האלה עלולות לגרום למיצוי מהיר של יציאות הצמתים הזמינות מתוך 2,768 שהוקצו לאשכול. כדי לחסוך ביציאות צמתים, משביתים את ההקצאה של יציאות צמתים למאזן העומסים על ידי הגדרת השדה allocateLoadBalancerNodePorts לערך false במפרט של שירות LoadBalancer. ההגדרה הזו מונעת מ-Kubernetes להקצות יציאות צמתים לשירותים מסוג LoadBalancer. מידע נוסף זמין במאמר השבתת הקצאת NodePort למאזן עומסים במסמכי Kubernetes.
כדי לבדוק את מספר היציאות שהוקצו, משתמשים בפקודה הבאה:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
מגבלות על חיבור צמתים של מאזן עומסים בחבילה
מספר החיבורים שמותר לכל צומת שמשמש לאיזון עומסים בחבילה (MetalLB) הוא 28,000. טווח היציאות הארעיות שמוגדר כברירת מחדל לחיבורים האלה הוא 32768-60999. אם חורגים ממגבלת החיבור, יכול להיות שהבקשות לשירות LoadBalancer ייכשלו.
אם אתם צריכים לחשוף שירות של איזון עומסים שיכול לטפל במספר גדול של חיבורים (למשל, עבור Ingress), מומלץ לשקול שיטה חלופית לאיזון עומסים כדי להימנע מהמגבלה הזו ב-MetalLB.
מכסות של אשכולות
כברירת מחדל, אפשר לרשום עד 250 אשכולות עם חברות גלובלית לכל צי. כדי לרשום עוד אשכולות ב-GKE Hub, אפשר לשלוח בקשה להגדלת המכסה במסוף Google Cloud :
מידע נוסף על מכסות של אשכולות שמבוססות על הגדרות החברות זמין במאמר מכסות הקצאה.
מידע על התאמה להיקף
המידע במסמך הזה רלוונטי לתכנון של הגדלת האשכולות. מידע נוסף זמין במאמר הגדלת הקיבולת של אשכולות Google Distributed Cloud.
לא מצאת מה שחיפשת? לוחצים על שליחת משוב ומספרים לנו מה חסר.