בדף הזה מוסברות המכסות והמגבלות של Google Distributed Cloud (תוכנה בלבד) בשרת פיזי עבור Google Cloud פרויקטים, אשכולות וצמתים.
מגבלות
בקטעים הבאים מפורטות כמה מגבלות בסיסיות על האשכולות. חשוב לקחת את המגבלות האלה בחשבון כשמתכננים את האפליקציות להפעלה ב-Google Distributed Cloud.
מספר מקסימלי של אשכולות משתמשים לכל אשכול אדמין
באמצעות אשכולות אדמין אפשר לנהל את מחזור החיים של אשכולות משתמשים והצמתים המשויכים שלהם. אשכולות אדמין שולטים בפעולות קריטיות של אשכולות משתמשים, כמו יצירת אשכולות, איפוס אשכולות או צמתים, שדרוג אשכולות ועדכון אשכולות. המספר הכולל של הצמתים באשכול המשתמשים הוא אחד מהגורמים העיקריים שמגבילים את הביצועים והמהימנות.
על סמך בדיקות שוטפות, אשכול אדמין יכול לתמוך באופן מהימן בעד 100 אשכולות משתמשים, כשכל אחד מהם כולל 10 צמתים, כלומר בסך הכול 1,000 צמתים.
מספר הפודים המקסימלי לכל אשכול משתמשים
מומלץ להגביל את מספר הפודים לכל אשכול משתמשים ל-15,000 או פחות. לדוגמה, אם באשכול יש 200 צמתים, צריך להגביל את מספר הפודים לכל צומת ל-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 נקודות קצה. המספר הזה הוא סכום כל הפודים שאליהם מתייחס שירות Kubernetes. אם שני שירותים מפנים לאותה קבוצה של פודים, המצב הזה נחשב לשתי קבוצות נפרדות של נקודות קצה. ההטמעה הבסיסית ב-RHEL גורמת להגבלה הזו, והיא לא הגבלה מובנית של Google Distributed Cloud.nftable
השבתה זמנית של אותות אכיפה
ב-RHEL, אין אמצעי הגנה. במערכות Ubuntu ו-Debian, מומלץ לעבור מ-nftables שמוגדר כברירת מחדל ל-iptables מדור קודם באשכולות גדולים.
GKE Dataplane V2
Google Distributed Cloud משתמש ב-GKE Dataplane V2, שהוא מישור נתונים של אשכול שמיושם באמצעות Cilium ו-eBPF, ומותאם לרשתות Kubernetes.
מגבלות של GKE Dataplane V2 NetworkPolicy
GKE Dataplane V2 משתמש ב-Cilium כדי לנהל משאבי NetworkPolicy Kubernetes. המגבלות הבאות חלות על האשכולות שלכם:
| מאפיין | מגבלות נתמכות |
|---|---|
| שיעור השינוי המקסימלי של תוויות במרחב שמות | לכל היותר, שינוי אחד בשעה לכל מרחב שמות.
ברוב המקרים, אין צורך בהגבלת מספר המשתמשים. כל עוד השינויים לא תכופים מדי, למשל כל שנייה, או שמספר זהויות 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. |
| המספר המקסימלי של קבוצות תוויות ייחודיות של Pod שנבחרו על ידי כללי בחירת המדיניות | 16,000 (גודל קבוע של מיפוי eBPF). רשומה נתונה במפת בוררי המדיניות מורכבת מהרכיבים הבאים: זהות אבטחה, יציאה ופרוטוקול. |
מגבלת eBPF ב-GKE 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.
לא מצאת מה שחיפשת? לוחצים על שליחת משוב ומספרים לנו מה חסר.