ב-Distributed Cloud software only for bare metal, המכסות והמגבלות חלות על פרויקטים, אשכולות וצמתים ב- Google Cloud . הספים האלה מגדירים את הרישומים הנתמכים של ה-fleet, את הקיבולות של האשכולות ואת מגבלות המשאבים של הצמתים, כדי לעזור לכם לתכנן ולהרחיב את הפריסות ב-Bare Metal.
מגבלות
בקטעים הבאים מפורטות כמה מגבלות בסיסיות של האשכולות. חשוב לקחת בחשבון את המגבלות האלה כשמתכננים את האפליקציות שיפעלו ב-Google Distributed Cloud.
מספר מקסימלי של אשכולות משתמשים לכל אשכול אדמין
אשכולות אדמין מנהלים את מחזור החיים של אשכולות המשתמשים והצמתים שמשויכים אליהם. אשכולות אדמין שולטים בפעולות קריטיות של אשכולות משתמשים, כמו יצירת אשכולות, איפוס של אשכולות או צמתים, שדרוג אשכולות ועדכון אשכולות. המספר הכולל של צומתי אשכולות המשתמשים הוא אחד הגורמים העיקריים שמגבילים את הביצועים והאמינות.
על סמך בדיקות שוטפות, אשכול אדמין יכול לתמוך באופן מהימן ב-100 אשכולות משתמשים לכל היותר, עם 10 צמתים בכל אחד, ובסך הכול 1,000 צמתים.
מספר הפודים המקסימלי לכל אשכול משתמשים
מומלץ להגביל את מספר ה-Pods לכל אשכול משתמש ל-15,000 או פחות. לדוגמה, אם באשכול יש 200 צמתים, צריך להגביל את מספר הפודים לכל צומת ל-75 או פחות. באופן דומה, אם רוצים להריץ 110 Pods לכל צומת, צריך להגביל את מספר הצמתים באשכול ל-136 או פחות. בטבלה הבאה מפורטות דוגמאות להגדרות מומלצות ולא מומלצות.
| פודים לכל צומת | צמתים בכל אשכול | Pods לכל אשכול | תוצאה |
|---|---|---|---|
| 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, כולל pod-ים שמריצים שירותי תוספים:
| סוג האשכול | הערך המינימלי המותר | הערך המקסימלי המומלץ | הערך המקסימלי המותר |
|---|---|---|---|
| כל אשכולות ה-HA ואשכולות המשתמשים שאינם HA | 32 | 110 | 250 |
| כל שאר האשכולות שהם לא HA | 64 | 110 | 250 |
מספר נקודות הקצה המקסימלי
ב-Red Hat Enterprise Linux (RHEL), יש מגבלה של 100,000 נקודות קצה ברמת האשכול. המספר הזה הוא הסכום של כל הפודים ששירות Kubernetes מפנה אליהם. אם שני שירותים מפנים לאותה קבוצת Pods, המצב הזה נחשב לשתי קבוצות נפרדות של נקודות קצה. המגבלה הזו נובעת מההטמעה הבסיסית של 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 כדי לנהל את משאבי NetworkPolicy ב-Kubernetes. המגבלות הבאות חלות על האשכולות:
| מאפיין | המגבלות הנתמכות |
|---|---|
| שיעור השינוי המקסימלי של תוויות מרחב השמות | אפשר לבצע שינוי אחד לכל היותר בשעה לכל מרחב שמות.
ברוב המקרים, המגבלה הזו לא נחוצה. כל עוד השינויים לא מתבצעים בתדירות גבוהה, למשל כל שנייה, או שמספר הזהויות של Cilium (קבוצות של תוויות ייחודיות) לא קרוב למגבלה: 16,000 קבוצות של תוויות עם מדיניות רשת ב-Kubernetes מסוג allow all, או 65,535 קבוצות של תוויות לכל אשכול. |
| מספר נקודות הקצה המקסימלי של שירות לכל אשכול | 100,000 נקודות קצה היא המגבלה שנבדקה ומומלצת. המגבלה המקודדת של נקודות קצה (endpoint) של שירותים היא 262,000. |
| מספר מקסימלי של כללים ומדיניות רשת ב-Kubernetes | עד 40,000 מדיניות רשת ב-Kubernetes ו-80,000 כללים. לדוגמה, אפשר לציין 40,000 מדיניות רשת ב-Kubernetes עם שני כללים לכל אחד, או 20,000 מדיניות רשת ב-Kubernetes עם ארבעה כללים לכל אחד. |
| קצב השינוי המקסימלי של מדיניות רשת ב-Kubernetes | עד 20 שינויים (יצירות או מחיקות) בשנייה. |
| המספר המקסימלי של קבוצות ייחודיות של תוויות פודים | 65,535 (216-1). זוהי המגבלה של זהות האבטחה של Cilium. |
| המספר המקסימלי של קבוצות ייחודיות של תוויות Pod שנבחרו על ידי בוררי מדיניות | 16,000 (הגודל הקבוע של מפת eBPF). רשומה נתונה במפת בורר המדיניות מורכבת מהרכיבים הבאים: זהות אבטחה, יציאה ופרוטוקול. |
מגבלת Dataplane V2 eBPF
מספר הרשומות המקסימלי ב-BPF lbmap ל-Dataplane V2 הוא 65,536. עלייה בתחומים הבאים יכולה לגרום לעלייה במספר הכולל של הרשומות:
- מספר השירותים
- מספר היציאות לכל שירות
- מספר הקצוות העורפיים לכל שירות
מומלץ לעקוב אחרי מספר הרשומות בפועל שמשמשות את האשכול כדי לוודא שלא חורגים מהמגבלה. כדי לקבל את הרשומות הנוכחיות, משתמשים בפקודה הבאה:
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 אשכולות עם מינויים גלובליים לכל Fleet. כדי לרשום עוד אשכולות ב-GKE Hub, אתם יכולים לשלוח בקשה להגדלת המכסה במסוף Google Cloud :
מידע נוסף על מכסות של אשכולות שמבוססות על הגדרות החברות זמין במאמר מכסות הקצאה.
מידע על התאמה לעומס (scaling)
המידע במסמך הזה רלוונטי לתכנון של הגדלת האשכולות. מידע נוסף זמין במאמר הרחבת אשכולות של Google Distributed Cloud.
לא מצאת מה שחיפשת? לוחצים על שליחת משוב ומספרים לנו מה חסר.