בדף הזה מוסבר על מכסות ומגבלות של תוכנת Distributed Cloud ל-Bare Metal בלבד, בפרויקטים, באשכולות ובצמתים של Google Cloud .
מגבלות
בקטעים הבאים מפורטות כמה מגבלות בסיסיות לגבי האשכולות. חשוב לקחת את המגבלות האלה בחשבון כשמתכננים את האפליקציות להרצה ב-Google Distributed Cloud.
מספר מקסימלי של אשכולות משתמשים לכל אשכול אדמין
אשכולות אדמין מנהלים את מחזור החיים של אשכולות משתמשים והצמתים המשויכים שלהם. אשכולות אדמין שולטים בפעולות קריטיות של אשכולות משתמשים, כמו יצירת אשכולות, איפוס אשכולות או צמתים, שדרוג אשכולות ועדכון אשכולות. המספר הכולל של צמתי אשכולות משתמשים הוא אחד מהגורמים העיקריים שמגבילים את הביצועים והמהימנות.
על סמך בדיקות שוטפות, אשכול אדמין יכול לתמוך באופן מהימן בעד 100 אשכולות משתמשים, שכל אחד מהם כולל 10 צמתים, כלומר בסך הכול 1,000 צמתים.
מספר הפודים המקסימלי לכל אשכול משתמשים
מומלץ להגביל את מספר הפודים לכל אשכול משתמש ל-15,000 או פחות. לדוגמה, אם באשכול יש 200 צמתים, צריך להגביל את מספר הפודים לכל צומת ל-75 או פחות. באופן דומה, אם רוצים להפעיל 110 פודים לכל צומת, צריך להגביל את מספר הצמתים באשכול ל-136 או פחות. בטבלה הבאה מופיעות דוגמאות להגדרות מומלצות ולא מומלצות.
| Pods per node | צמתים לכל אשכול | Pods per Cluster | תוצאה |
|---|---|---|---|
| 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 נקודות קצה. המספר הזה הוא סכום כל הפודים שהשירות של Kubernetes מפנה אליהם. אם שני שירותים מפנים לאותה קבוצה של פודים, המצב הזה נחשב לשתי קבוצות נפרדות של נקודות קצה. המגבלה הזו נובעת מההטמעה הבסיסיתnftable ב-RHEL, ולא מהמגבלות המובנות של Google Distributed Cloud.
השבתה זמנית של אותות אכיפה
ב-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
מומלץ גם להשתמש בצינור עיבוד נתונים משלכם למעקב כדי לאסוף מדדים מ-anetd DaemonSet. כדי לזהות מתי מספר הרשומות גורם לבעיות, צריך לעקוב אחרי התנאים הבאים:
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. מידע נוסף זמין במאמר Disabling load balancer NodePort allocation (השבתת הקצאה של 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.
לא מצאת מה שחיפשת? לוחצים על שליחת משוב ומספרים לנו מה חסר.