בדף הזה מתוארות שיטות מומלצות ליצירה, להגדרה ולהפעלה של אשכולות שנוצרו באמצעות תוכנת Google Distributed Cloud ל-VMware בלבד, כדי להתאים לעומסי עבודה שמתקרבים למגבלות הסקיילביליות של Kubernetes.
כללים למתן שמות לאשכולות
לכל פרויקט ב- Google Cloud :
- לכל אשכול משתמשים צריך להיות שם ייחודי בכל אשכולות האדמין שנמצאים בפרויקט Google Cloud אחד.
מגבלות מדרגיות
כשאתם מתכננים את האפליקציות, חשוב לקחת בחשבון את המגבלות הבאות:
אם אשכול מתקדם לא מופעל:
כל אשכול אדמין תומך בעד 100 אשכולות משתמש, כולל אשכולות משתמש עם זמינות גבוהה (HA) וללא זמינות גבוהה, באמצעות מצב איזון עומסים מקובץ (MetalLB) או (איזון עומסים ידני).
כל אשכול משתמשים תומך בעד:
500 צמתים באמצעות מצב איזון עומסים מקובץ (MetalLB)
15,000 פודים
500 שירותי LoadBalancer באמצעות מצב איזון עומסים בחבילה (MetalLB).
בכל צומת אפשר ליצור עד 110 Pods (כל Pod יכול להכיל 1-2 קונטיינרים). זה כולל Pods שמריצים שירותי מערכת של תוספים.
אם אשכול מתקדם מופעל
כל אשכול אדמין תומך בעד 100 אשכולות משתמשים. אשכולות המשתמשים חייבים להיות אשכולות בזמינות גבוהה (HA), באמצעות מצב איזון עומסים בחבילה (MetalLB) או (מאזן עומסים ידני).
כל אשכול משתמשים תומך בעד:
500 צמתים באמצעות מצב איזון עומסים מקובץ (MetalLB).
15,000 פודים
500 שירותי LoadBalancer באמצעות מצב איזון עומסים בחבילה (MetalLB).
בכל צומת אפשר ליצור עד 110 Pods (כל Pod יכול להכיל 1-2 קונטיינרים). זה כולל Pods שמריצים שירותי מערכת של תוספים.
המספר הכולל של הצמתים, שכולל את צומתי מישור הבקרה של אשכול האדמין + כל צומתי מישור הבקרה של אשכול המשתמש + צומתי העובדים, לא יכול להיות יותר מ-500 צמתים.
הסבר על המגבלות
מכיוון ש-Google Distributed Cloud היא מערכת מורכבת עם שטח אינטגרציה גדול, יכולת ההתאמה לעומס (scalability) של האשכול כוללת הרבה מאפיינים שקשורים זה לזה. לדוגמה, אפשר לשנות את קנה המידה של Google Distributed Cloud באמצעות מספר הצמתים, ה-Pods או השירותים. הרחבה של יותר ממאפיין אחד בכל פעם עלולה לגרום לבעיות, אפילו באשכולות קטנים יותר. לדוגמה, תזמון של 110 Pods לכל צומת באשכול של 500 צמתים יכול לחרוג ממספר ה-Pods, ה-Pods לכל צומת והצמתים.
פרטים נוספים זמינים במאמר ספי מדרגיות של Kubernetes.
מגבלות הסקיילביליות מושפעות גם מהגדרות ה-vSphere ומהחומרה שעליה פועל האשכול. המגבלות האלה נבדקות בסביבה שכנראה שונה מהסביבה שלכם. לכן, יכול להיות שלא תקבלו את אותם מספרים בדיוק אם הסביבה הבסיסית היא הגורם המגביל.
הכנה להרחבה
כשאתם מתכוננים להרחיב את אשכולות האדמין או אשכולות המשתמשים, כדאי להביא בחשבון את הדרישות והמגבלות הבאות.
דרישות לגבי מעבד (CPU), זיכרון ואחסון
דרישות המעבד, ה-RAM והאחסון לכל מכונה וירטואלית בנפרד.
דרישות קלט/פלט של דיסק ורשת
עומסי עבודה עתירי נתונים ורכיבים מסוימים במישור הבקרה רגישים לזמן האחזור של קלט/פלט בדיסק וברשת. לדוגמה, בדרך כלל נדרשות 500 פעולות IOPS רציפות (למשל, כונן SSD מקומי טיפוסי או מכשיר לאחסון ולאחזור בלוקים וירטואלי עם ביצועים גבוהים) כדי ש-etcd יפעל בצורה יציבה ובביצועים טובים באשכול עם עשרות צמתים ואלפי Pods.
כתובת ה-IP של הצומת
כל צומת דורש כתובת IP אחת שהוקצתה באופן סטטי או באמצעות DHCP.
לדוגמה, צריך 307 כתובות IP בהגדרה עם אשכול משתמש אחד ללא HA עם 50 צמתים ואשכול משתמש אחד עם HA עם 250 צמתים.
בטבלה הבאה מוצג פירוט של כתובות ה-IP:
| סוג הצומת | מספר כתובות ה-IP |
|---|---|
| מכונות וירטואליות של מישור הבקרה באשכול האדמין | 3 |
| מכונה וירטואלית של מישור הבקרה באשכול משתמש 1 (ללא זמינות גבוהה) | 1 |
| מכונות וירטואליות של צומת עובד באשכול משתמשים 1 | 50 |
| מכונות וירטואליות של מישור הבקרה באשכול משתמש 2 (HA) | 3 |
| מכונות וירטואליות של צומתי עובדים באשכול משתמשים 2 | 250 |
| סה"כ | 307 |
הפעלת אשכולות רבים של משתמשים באשכול אדמין
כשאתם מתכוננים להפעיל הרבה אשכולות של משתמשים באשכול אדמין, בצעו את השלבים הבאים בזמן יצירת אשכול האדמין.
בלוק CIDR של Pod באשכול האדמין
בלוק ה-CIDR של Pod הוא בלוק ה-CIDR של כל ה-Pods באשכול אדמין. הוא מוגדר באמצעות השדה network.podCIDR ב-admin-cluster.yaml.
מהטווח הזה, בלוקים קטנים יותר של /24 מוקצים לכל צומת. אם בכל אשכולות המשתמשים מופעל Controlplane V2, לאשכול האדמין יש רק שלושה צמתים, ויש הרבה כתובות IP זמינות לפודים. עם זאת, בכל פעם שיוצרים אשכול משתמש שמשתמש ב-kubeception במקום ב-Controlplane V2, נוספים לאשכול הניהול צומת אחד או שלושה צמתים:
כל אשכול משתמשים של kubeception בזמינות גבוהה (HA) מוסיף שלושה צמתים לאשכול האדמין.
כל אשכול משתמשים של kubeception ללא זמינות גבוהה מוסיף צומת אחד לאשכול האדמין.
אם אתם צריכים אשכול אדמין עם N צמתים, אתם צריכים לוודא שבלוק ה-CIDR של ה-Pod גדול מספיק כדי לתמוך בבלוקים של N /24.
בטבלה הבאה מתואר המספר המקסימלי של צמתים שנתמכים בגדלים שונים של בלוקי CIDR של Pod:
| גודל בלוק ה-CIDR של Pod | מספר הצמתים המקסימלי הנתמך |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
בלוק ה-CIDR של Pod שמוגדר כברירת מחדל באשכול אדמין הוא 192.168.0.0/16, והוא תומך ב-256 צמתים.
באשכול אדמין עם 100 אשכולות משתמשים של kubeception בזמינות גבוהה, יש 3 צמתים של מישור הבקרה של אשכול האדמין ו-300 צמתים של מישור הבקרה של אשכול המשתמשים. מספר הצמתים הכולל הוא 303 (יותר מ-256). לכן, כדי לתמוך בעד 100 אשכולות משתמשים של kubeception בזמינות גבוהה, צריך לעדכן את בלוק ה-CIDR של Pod ל-/15.
כדי להגדיר את בלוק ה-CIDR של Pod, מגדירים את השדה network.podCIDR בקובץ התצורה של אשכול האדמין.
בלוק CIDR של שירות באשכול האדמין
בלוק ה-CIDR של השירות הוא בלוק ה-CIDR של כל השירותים באשכול אדמין.
הוא מוגדר באמצעות השדה network.serviceCIDR ב-admin-cluster.yaml.
בטבלה הבאה מתואר המספר המקסימלי של שירותים שנתמכים בגדלים שונים של בלוקי CIDR של שירותים:
| גודל בלוק ה-CIDR של השירות | המספר המקסימלי של שירותים נתמכים |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
ערך ברירת המחדל הוא 10.96.232.0/24, שתומך ב-256 שירותים.
כל אשכול משתמשים ב-kubeception משתמש ב-6 שירותים, ומישור הבקרה של אשכול האדמין משתמש ב-14 שירותים. לכן, כדי להריץ 100 אשכולות משתמשים של kubeception, צריך לשנות את בלוק ה-CIDR של השירות באשכול האדמין כך שישתמש בטווח /22.
Cloud Logging ו-Cloud Monitoring לאשכולות משתמשים ב-kubeception
בעזרת Cloud Logging ו-Cloud Monitoring אתם יכולים לעקוב אחרי המשאבים שלכם.
השימוש במעבד (CPU) ובזיכרון של רכיבי הרישום ביומן והמעקב שנפרסו באשכול אדמין, משתנה בהתאם למספר אשכולות המשתמשים של kubeception.
בטבלה הבאה מתוארים המעבד והזיכרון של צומת אשכול האדמין שנדרשים כדי להריץ מספר גדול של אשכולות משתמשים ב-kubeception:
| מספר אשכולות המשתמשים ב-kubeception | מעבד (CPU) של צומת באשכול אדמין | זיכרון של צומת באשכול אדמין |
|---|---|---|
| 0 עד 10 | 4 מעבדים (CPU) | 16GB |
| 11 עד 20 | 4 מעבדים (CPU) | 32GB |
| 20 עד 100 | 4 מעבדים (CPU) | 90GB |
לדוגמה, אם יש 2 צומתי אשכולות של אדמין, ולכל אחד מהם יש 4 מעבדים וזיכרון בנפח 16GB, אפשר להריץ בין 0 ל-10 אשכולות משתמשים של kubeception. כדי ליצור יותר מ-20 אשכולות משתמשים ב-kubeception, קודם צריך לשנות את גודל הזיכרון של צומת אשכול האדמין מ-16GB ל-90GB.
צומתי אשכולות של אדמינים כשאשכולות מתקדמים מופעלים
השימוש ב-CPU ובזיכרון של רכיבי מחזור החיים שנפרסו באשכול אדמין משתנה בהתאם למספר הכולל של כל הצמתים (המספר הכולל של הצמתים שכולל את צומתי מישור הבקרה של אשכול האדמין + כל צומתי מישור הבקרה של אשכול המשתמש + צומתי העובדים)
בטבלה הבאה מתוארת כמות המעבד (CPU) והזיכרון של צומת אשכול האדמין שנדרשת כדי להריץ מספר גדול של כל הצמתים שהוא מנהל:
| מספר הצמתים הכולל | מעבד (CPU) של צומת באשכול אדמין | זיכרון של צומת באשכול אדמין |
|---|---|---|
| 0 עד 20 | 4 מעבדים (CPU) | 16GB |
| 21 עד 100 | 8 מעבדים (CPU) | 16GB |
| 101 עד 500 | 16 מעבדים (CPU) | 32GB |
לדוגמה, אם יש 3 צמתים של אשכול אדמין ולכל אחד מהם יש 4 מעבדים וזיכרון בנפח 16GB, אפשר להריץ אשכול משתמש אחד עם זמינות גבוהה עם 14 צמתים עובדים. כדי ליצור יותר מ-20 אשכולות מתקדמים של משתמשים, כשבכל אשכול משתמשים יש יותר מ-10 צמתים, קודם צריך לשנות את גודל הזיכרון של צומת אשכול האדמין מ-16GB ל-32GB.
GKE Hub
כברירת מחדל, אפשר לרשום עד 250 אשכולות עם מינויים גלובליים לכל Fleet. כדי לרשום עוד אשכולות ב-GKE Hub, אתם יכולים לשלוח בקשה להגדלת המכסה במסוף Google Cloud :
מידע נוסף על מכסות של אשכולות שמבוססות על הגדרות החברות זמין במאמר מכסות הקצאה.
הפעלת הרבה צמתים ו-Pod באשכול משתמשים
כשמתכוננים להפעיל הרבה צמתים ופודים באשכול משתמש, צריך לבצע את השלבים הבאים בזמן יצירת אשכול המשתמש.
בלוק CIDR של Pod באשכול המשתמשים
בלוק ה-CIDR של Pod הוא בלוק ה-CIDR של כל ה-Pods באשכול משתמש. הוא מוגדר באמצעות השדה network.podCIDR ב-user-cluster.yaml.
מהטווח הזה, בלוק קטן יותר של /24 מוקצה לכל צומת. אם אתם צריכים אשכול של N צמתים, אתם צריכים לוודא שהבלוק הזה גדול מספיק כדי לתמוך בבלוקים של N /24.
בטבלה הבאה מתואר המספר המקסימלי של צמתים שנתמכים בגדלים שונים של בלוקי CIDR של Pod:
| גודל בלוק ה-CIDR של Pod | מספר הצמתים המקסימלי הנתמך |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
בלוק ה-CIDR של Pod שמוגדר כברירת מחדל הוא 192.168.0.0/16, שתומך ב-256 צמתים. לדוגמה, כדי ליצור אשכול עם 500 צמתים, צריך לשנות את בלוק ה-CIDR של הפוד באשכול המשתמשים כך שישתמש בטווח /15.
בלוק CIDR של שירות באשכול המשתמשים
בלוק ה-CIDR של השירות הוא בלוק ה-CIDR של כל השירותים באשכול משתמש. הוא מוגדר באמצעות השדה network.serviceCIDR ב-user-cluster.yaml.
בטבלה הבאה מתואר המספר המקסימלי של שירותים שנתמכים בגדלים שונים של בלוקי CIDR של שירותים:
| גודל בלוק ה-CIDR של השירות | המספר המקסימלי של שירותים נתמכים |
|---|---|
| /21 | 2,048 |
| /20 | 4,096 |
| /19 | 8,192 |
| /18 | 16,384 |
צמתים של מישור הבקרה באשכולות של משתמשים
השימוש בזיכרון של רכיבי מישור הבקרה של אשכול המשתמש משתנה בהתאם למספר הצמתים באשכול המשתמש.
בטבלה הבאה מפורטים המעבד והזיכרון שנדרשים לצומת של מישור הבקרה באשכול המשתמש, בהתאם לגודל של אשכול המשתמש:
| מספר הצמתים באשכול המשתמשים | מעבד (CPU) של צומת במישור הבקרה | זיכרון של צומת במישור הבקרה |
|---|---|---|
| 0 עד 20 | 3 מעבדים (CPU) | 5GB |
| 21 עד 75 | 3 מעבדים (CPU) | 6GB |
| 76 עד 250 | 4 מעבדים (CPU) | 8GB |
| 251 עד 500 | 4 מעבדים (CPU) | 16GB |
לדוגמה, כדי ליצור יותר מ-250 צמתים באשכול משתמש, צריך להשתמש בצמתים של מישור הבקרה של אשכול המשתמש עם זיכרון של 16GB לפחות.
אפשר לשנות את המפרט של צומת מישור הבקרה של אשכול המשתמשים באמצעות השדה masterNode ב-user-cluster.yaml.
Dataplane v2
באשכולות משתמשים עם 500 צמתים שמשתמשים ב-Dataplane V2, מומלץ להשתמש בזיכרון בנפח 120GB וב-32 ליבות מעבד (CPU) לצמתים של מישור הבקרה של אשכול המשתמשים.
Cloud Logging ו-Cloud Monitoring
בעזרת Cloud Logging ו-Cloud Monitoring אתם יכולים לעקוב אחרי המשאבים שלכם.
השימוש במעבד ובזיכרון של הסוכנים באשכול שנפרסו באשכול משתמשים משתנה בהתאם למספר הצמתים וה-Pods באשכול המשתמשים.
רכיבי Cloud Logging ו-Monitoring, כמו prometheus-server ו-stackdriver-prometheus-sidecar, משתמשים במשאבי מעבד (CPU) וזיכרון שונים בהתאם למספר הצמתים ולמספר ה-Pods. לפני שמרחיבים את האשכול, מגדירים את בקשת המשאבים ואת המגבלה בהתאם לשימוש הממוצע המשוער ברכיבים האלה. בטבלה הבאה מוצגות הערכות לגבי כמות השימוש הממוצעת בכל רכיב:
| מספר הצמתים | שם המאגר | שימוש משוער במעבד (CPU) | שימוש משוער בזיכרון | ||
|---|---|---|---|---|---|
| 0 פודים לצומת | 30 פודים לכל צומת | 0 פודים לצומת | 30 פודים לכל צומת | ||
| 3 עד 50 | prometheus-server | 100 מ' | 390 מ' | 650M | 1.3G |
| stackdriver-prometheus-sidecar | 100 מ' | 340 מ' | 1.5G | 1.6G | |
| 51 עד 100 | prometheus-server | 160 מטרים | 500 מ' | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200 מטר | 500 מ' | 1.9G | 5.7G | |
| 101 עד 250 | prometheus-server | 400 מ' | 2,500 מ' | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400 מ' | 1,300 מ' | 7.5G | 12G | |
| 250 עד 500 | prometheus-server | 1,200 מטרים | 2,600 מ' | 22G | 25G |
| stackdriver-prometheus-sidecar | 400 מ' | 2,250 מטרים | 65G | 78G | |
חשוב לוודא שיש לכם צמתים גדולים מספיק כדי לתזמן את הרכיבים של Cloud Logging ו-Cloud Monitoring. אחת הדרכים לעשות זאת היא ליצור קודם אשכול קטן, לערוך את משאבי הרכיבים של Cloud Logging ו-Cloud Monitoring לפי הטבלה שלמעלה, ליצור מאגר צמתים כדי להתאים את הרכיבים, ואז להגדיל בהדרגה את האשכול לגודל גדול יותר.
אפשר לבחור להחזיק מאגר צמתים שיהיה גדול מספיק רק לרכיבי המעקב והרישום ביומן, כדי למנוע תזמון של Pods אחרים למאגר הצמתים. כדי לעשות את זה, צריך להוסיף את הכתמים הבאים למאגר הצמתים:
taints:
- effect: NoSchedule
key: node-role.gke.io/observabilityכך רכיבים אחרים לא יתוזמנו במאגר הצמתים, ועומסי העבודה של המשתמשים לא יפונו בגלל צריכת המשאבים של רכיבי המעקב.
מאזן עומסים
השירותים שמוזכרים בקטע הזה מתייחסים לשירותי Kubernetes מסוג LoadBalancer.
יש מגבלה על מספר הצמתים באשכול ועל מספר השירותים שאפשר להגדיר במאזן העומסים.
באיזון עומסים מקובץ (Seesaw), יש גם מגבלה על מספר בדיקות התקינות. מספר בדיקות התקינות תלוי במספר הצמתים ובמספר השירותים המקומיים של תעבורת הנתונים. שירות מקומי של תעבורת נתונים הוא שירות שבו externalTrafficPolicy מוגדר ל-Local.
בטבלה הבאה מפורט המספר המקסימלי של שירותים, צמתים ובדיקות תקינות לאיזון עומסים מקובץ (Seesaw) ולאיזון עומסים משולב (F5):
| איזון עומסים מקובץ (Seesaw) | איזון עומסים משולב (F5) | |
|---|---|---|
| Max Services | 500 | 250 2 |
| מספר הצמתים המקסימלי | 500 | 250 2 |
| בדיקות תקינות מקסימליות | N + (L * N) <= 10K, כאשר N הוא מספר הצמתים ו-L הוא מספר השירותים המקומיים של התנועה 1 | לא רלוונטי 2 |
1 לדוגמה, נניח שיש לכם 100 צמתים ו-99 שירותים מקומיים לתעבורת נתונים. מספר בדיקות התקינות הוא 100 + (99 * 100) = 10,000, וזה לא חורג מהמגבלה של 10,000.
2 למידע נוסף, פנו אל F5. המספר הזה מושפע מגורמים כמו מספר הדגם של חומרת F5, המעבד או הזיכרון של המכונה הווירטואלית והרישיונות.
רכיבי מערכת להתאמה אוטומטית לעומס (automatic scaling)
Google Distributed Cloud מבצעת התאמה אוטומטית לעומס של רכיבי המערכת באשכולות של המשתמשים בהתאם למספר הצמתים, בלי שתצטרכו לשנות את ההגדרות. אתם יכולים להשתמש במידע שבקטע הזה כדי לתכנן את המשאבים.
ב-Google Distributed Cloud, המערכת משתמשת ב-addon-resizer כדי לשנות את הגודל של בקשות/מגבלות המעבד (CPU) והזיכרון של רכיבי המערכת הבאים, וכך מבצעת התאמה אנכית של קנה המידה באופן אוטומטי:
kube-state-metrics הוא פריסה שפועלת בצומתי העובדים של האשכול, שמאזינה לשרת ה-API של Kubernetes ויוצרת מדדים לגבי מצב האובייקטים. הבקשות והמגבלות של המעבד (CPU) והזיכרון משתנות בהתאם למספר הצמתים.
בטבלה הבאה מתוארות בקשות המשאבים או המגבלות שהמערכת מגדירה, בהתאם למספר הצמתים באשכול:
מספר הצמתים בקשה/מגבלה משוערת1 של מעבד (CPU) (באלפיות) בקשה/מגבלה משוערת1 של זיכרון (Mi) 3 עד 5 105 110 6 עד 500 100 + num_nodes 100 + (2 * num_nodes) 1 יש מרווח של +-5% כדי להפחית את מספר ההפעלות מחדש של הרכיבים במהלך ההתאמה לעומס.
לדוגמה, באשכול עם 50 צמתים, בקשת המעבד (CPU) והמגבלה שלו מוגדרות ל-150m/150m, ובקשת הזיכרון והמגבלה שלו מוגדרות ל-200Mi/200Mi. באשכול עם 250 צמתים, בקשת המעבד (CPU) והמגבלה שלו מוגדרות ל-350m/350m, ובקשת הזיכרון והמגבלה שלו מוגדרות ל-600Mi.
metrics-server הוא פריסה שפועלת בצומתי עובדים של אשכולות, שמשמשת את צינורות עיבוד הנתונים המובנים של Kubernetes להתאמה אוטומטית לעומס. הבקשה והמגבלות של המעבד (CPU) והזיכרון משתנות בהתאם למספר הצמתים.
ב-Google Distributed Cloud, המערכת מבצעת באופן אוטומטי התאמה אופקית לעומס (horizontal scaling) גם באשכולות אדמין וגם באשכולות משתמשים, על ידי התאמה לעומס של מספר הרפליקות של רכיבי המערכת הבאים:
core-dns הוא פתרון ה-DNS שמשמש לזיהוי שירותים. הוא פועל כפריסה בצומתי עובדים של אשכול משתמשים. Google Distributed Cloud משנה באופן אוטומטי את מספר הרפליקות בהתאם למספר הצמתים וליבות המעבד (CPU) באשכול. בכל הוספה או מחיקה של 16 צמתים או 256 ליבות, רפליקה אחת מתווספת או נמחקת. אם יש לכם אשכול של
Nצמתים ו-Cליבות, אתם יכולים לצפות ל-max(N/16, C/256)רפליקות.calico-typha הוא רכיב לתמיכה ברשתות של Pods. הוא פועל כפריסה בצומתי עובדים של אשכולות משתמשים. ב-Google Distributed Cloud, מספר הרפליקות של calico-typha משתנה באופן אוטומטי בהתאם למספר הצמתים באשכול:
מספר הצמתים (N) מספר הרפליקות של calico-typha N = 1 1 1 < N < 200 2 N >= 200 3 או יותר Istio ingress-gateway הוא הרכיב שתומך ב-ingress באשכול, והוא פועל כ-Deployment בצומתי העובדים של אשכול המשתמשים. בהתאם לכמות התנועה ש-ingress-gateway מטפל בה, Google Distributed Cloud משתמש ב-Horizontal Pod Autoscaler כדי לשנות את מספר הרפליקות בהתאם לשימוש שלהן במעבד (CPU), עם מינימום של 2 רפליקות ומקסימום של 5 רפליקות.
שרת ה-proxy של רשת konnectivity (KNP) מספק שרת proxy ברמת ה-TCP לתעבורת נתונים יוצאת מצומתי מישור הבקרה של אשכול המשתמשים. הוא מעביר את תעבורת הנתונים היוצאת של kube-apiserver של המשתמש שמיועדת לצומתי אשכול המשתמש. סוכן Konnectivity פועל כפריסה בצומתי עובדים של אשכולות משתמשים. ב-Google Distributed Cloud, מספר הרפליקות של סוכן konnectivity משתנה באופן אוטומטי בהתאם למספר הצמתים באשכול.
מספר הצמתים (N) מספר הרפליקות של סוכן Konnectivity 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 ומעלה
שיטות מומלצות
בקטע הזה מתוארות שיטות מומלצות לשינוי קנה המידה של המשאבים.
שינוי קנה המידה של האשכול בשלבים
יצירת צומת Kubernetes כוללת שכפול של תבנית קובץ האימג' של מערכת ההפעלה של הצומת לקובץ דיסק חדש, שהיא פעולת vSphere שדורשת הרבה קלט/פלט. אין בידוד קלט/פלט בין פעולת השכפול לבין פעולות הקלט/פלט של עומס העבודה. אם נוצרים יותר מדי צמתים בו-זמנית, פעולות השכפול נמשכות זמן רב ועלולות להשפיע על הביצועים והיציבות של האשכול ושל עומסי העבודה הקיימים.
חשוב לוודא שהאשכול מוגדל בשלבים, בהתאם למשאבי vSphere. לדוגמה, כדי לשנות את הגודל של אשכול מ-3 ל-500 צמתים, כדאי לשנות את הגודל בשלבים מ-150 ל-350 ואז ל-500, כדי להפחית את העומס על התשתית של vSphere.
אופטימיזציה של ביצועי קלט/פלט בדיסק של etcd
etcd הוא מאגר של ערכי מפתחות שמשמש כמאגר הגיבוי של Kubernetes לכל נתוני האשכול. הביצועים והיציבות שלו קריטיים לתקינות האשכול, והם רגישים לזמן האחזור של קלט/פלט (I/O) בדיסק וברשת.
כדי לשפר את ביצועי הקלט/פלט של מאגר הנתונים של vSphere שמשמש למכונות הווירטואליות של מישור הבקרה, כדאי לפעול לפי ההמלצות הבאות:
- פועלים לפי דרישות החומרה של etcd.
- השתמשו ב-SSD או בכל אחסון פלאש.
זמן אחזור של כמה מאות אלפיות השנייה מצביע על צוואר בקבוק בדיסק או בקלט/פלט של הרשת, ועלול לגרום לאשכול לא תקין. עוקבים אחרי המדדים הבאים של זמן האחזור של קלט/פלט ב-etcd ומגדירים להם ערכי סף להתראות:
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
אופטימיזציה של ביצועי הקלט/פלט של דיסק האתחול של הצומת
פודים משתמשים באחסון זמני לפעולות הפנימיות שלהם, כמו שמירת קבצים זמניים. אחסון זמני נצרך על ידי השכבה הניתנת לכתיבה של הקונטיינר, ספריית היומנים ונפחי emptyDir. אחסון זמני מגיע ממערכת הקבצים של הצומת, שמגובה על ידי דיסק האתחול של הצומת.
בצמתים של Kubernetes אין בידוד של קלט/פלט באחסון, ולכן אפליקציות שצורכות קלט/פלט גבוה מאוד באחסון הזמני שלהן עלולות לגרום לחוסר יציבות בצומת, כי הן מונעות מרכיבי מערכת כמו Kubelet ו-Docker daemon לקבל משאבים.
חשוב לוודא שמאפייני הביצועים של הקלט/פלט במאגר הנתונים שבו מוקצים דיסקי האתחול, יכולים לספק את הביצועים המתאימים לשימוש של האפליקציה באחסון זמני ובתנועת רישום ביומן.
מעקב אחרי תחרות על משאבים פיזיים
חשוב לשים לב ליחסים בין vCPU ל-pCPU ולהקצאת יתר של זיכרון. יחס לא אופטימלי או תחרות על הזיכרון במארחים הפיזיים עלולים לגרום לפגיעה בביצועים של המכונה הווירטואלית. כדאי לעקוב אחרי ניצול המשאבים הפיזיים ברמת המארח, ולהקצות מספיק משאבים להפעלת האשכולות הגדולים.