מדרגיות

בדף הזה מתוארות שיטות מומלצות ליצירה, להגדרה ולהפעלה של אשכולות שנוצרו באמצעות Google Distributed Cloud (תוכנה בלבד) ל-VMware, כדי להתאים לעומסי עבודה שמתקרבים למגבלות של יכולת ההתאמה של Kubernetes.

כללים למתן שמות לאשכולות

לכל Google Cloud פרויקט:

  • לכל אשכול משתמשים צריך להיות שם ייחודי בכל אשכולות האדמין שנמצאים בפרויקט Google Cloud יחיד.

מגבלות מדרגיות

כשמעצבים את האפליקציות, חשוב לקחת בחשבון את המגבלות הבאות:

  • אם אשכול מתקדם לא מופעל:

    • כל אשכול אדמין תומך בעד 100 אשכולות משתמשים, כולל אשכולות משתמשים עם זמינות גבוהה (HA) ואשכולות משתמשים ללא HA, באמצעות מצב איזון עומסים בחבילה (MetalLB) או (מאזן עומסים ידני).

    • כל אשכול משתמשים תומך בעד:

      • ‫500 צמתים באמצעות מצב איזון עומסים בחבילה (MetalLB)

      • ‫15,000 טבליות

      • ‫500 שירותים מסוג LoadBalancer באמצעות מצב איזון עומסים בחבילה (MetalLB).

    • לכל צומת אפשר ליצור עד 110 פודים (כל פוד יכול לכלול 1-2 קונטיינרים). זה כולל קבוצות Pod שמריצות שירותי מערכת של תוספים.

  • אם אשכול מתקדם מופעל

    • כל אשכול אדמין תומך בעד 100 אשכולות משתמשים. אשכולות המשתמשים צריכים להיות אשכולות עם זמינות גבוהה (HA), באמצעות מצב איזון עומסים בחבילה (MetalLB) או (מאזן עומסים ידני).

    • כל אשכול משתמשים תומך בעד:

      • ‫500 צמתים באמצעות מצב איזון עומסים בחבילה (MetalLB).

      • ‫15,000 טבליות

      • ‫500 שירותים מסוג LoadBalancer באמצעות מצב איזון עומסים בחבילה (MetalLB).

    • לכל צומת אפשר ליצור עד 110 פודים (כל פוד יכול לכלול 1-2 קונטיינרים). זה כולל קבוצות Pod שמריצות שירותי מערכת של תוספים.

    • המספר הכולל של הצמתים, שכולל צמתים של מישור הבקרה של אשכול האדמין + כל הצמתים של מישור הבקרה של אשכול המשתמש + צמתים של עובדים, לא יכול להיות יותר מ-500 צמתים.

הסבר על המגבלות

‫Google Distributed Cloud היא מערכת מורכבת עם שטח אינטגרציה גדול, ולכן מדרגיות של אשכולות כוללת הרבה מימדים שקשורים זה לזה. לדוגמה, אפשר להגדיל את הקיבולת של Google Distributed Cloud באמצעות מספר הצמתים, ה-Pods או השירותים. מתיחה של יותר ממימד אחד בו-זמנית עלולה לגרום לבעיות גם באשכולות קטנים יותר. לדוגמה, תזמון של 110 פודים לכל צומת באשכול של 500 צמתים עלול לחרוג מהמספר המקסימלי של פודים, פודים לכל צומת וצמתים.

פרטים נוספים זמינים במאמר סף המדרגיות של Kubernetes.

המגבלות על יכולת ההרחבה תלויות גם בהגדרות של vSphere ובחומרה שבה פועל האשכול. האימות של המגבלות האלה מתבצע בסביבה שסביר להניח ששונה מהסביבה שלכם. לכן, יכול להיות שלא תקבלו את המספרים המדויקים אם הסביבה הבסיסית היא הגורם המגביל.

הכנות להרחבת הפעילות

כשמתכוננים להרחבת אשכולות אדמין או אשכולות משתמשים, חשוב לקחת בחשבון את הדרישות וההגבלות הבאות.

דרישות המעבד (CPU), הזיכרון והאחסון

אפשר לעיין בדרישות לגבי מעבד, זיכרון RAM ואחסון לכל מכונה וירטואלית בנפרד.

דרישות קלט/פלט (I/O) של דיסק ורשת

עומסי עבודה (workloads) שדורשים הרבה נתונים ורכיבים מסוימים במישור הבקרה רגישים לזמן האחזור של קלט/פלט בדיסק וברשת. לדוגמה, בדרך כלל נדרשים 500 IOPS רציפים (למשל, SSD מקומי טיפוסי או מכשיר בלוקים וירטואלי עם ביצועים גבוהים) לביצועים וליציבות של etcd באשכול עם עשרות צמתים ואלפי Pods.

כתובת ה-IP של הצומת

כל צומת דורש כתובת IP אחת שמוקצית באמצעות DHCP או כתובת IP קבועה.

לדוגמה, צריך 307 כתובות IP בהגדרה עם קלאסטר משתמשים אחד שאינו HA עם 50 צמתים וקלאסטר משתמשים אחד HA עם 250 צמתים.

בטבלה הבאה מוצג פירוט של כתובות ה-IP:

סוג הצומת מספר כתובות ה-IP
מכונות VM של מישור הבקרה באשכול אדמין 3
מכונה וירטואלית של מישור הבקרה של אשכול משתמשים 1 (לא HA) 1
מכונות וירטואליות של צומת עובד באשכול משתמש 1 50
מכונות VM במישור הבקרה של אשכול משתמשים 2 (זמינות גבוהה) 3
מכונות וירטואליות של צומתי עובדים באשכול משתמש 2 250
סה"כ 307

הפעלת אשכולות משתמשים רבים באשכול אדמין

כשמתכוננים להפעיל הרבה אשכולות משתמשים באשכול אדמין, צריך לבצע את השלבים הבאים כשיוצרים את אשכול האדמין.

חסימת CIDR של ה-Pod באשכול האדמין

בלוק ה-CIDR של ה-Pod הוא בלוק ה-CIDR של כל ה-Pods באשכול אדמין. ההגדרה מתבצעת דרך השדה network.podCIDR ב-admin-cluster.yaml.

מתוך הטווח הזה, מוקצים לכל צומת בלוקים קטנים יותר מסוג ‎ /24. אם בכל אשכולות המשתמשים שלכם מופעל Controlplane V2, באשכול האדמין יש רק שלושה צמתים, ויש הרבה כתובות IP של Pod שזמינות. עם זאת, בכל פעם שיוצרים אשכול משתמשים שמשתמש ב-kubeception במקום ב-Controlplane V2, מתווסף לאשכול האדמין צומת אחד או שלושה צמתים:

  • כל אשכול משתמשים עם זמינות גבוהה (HA) של kubeception מוסיף שלושה צמתים לאשכול האדמין.

  • כל אשכול משתמשים של kubeception שאינו HA מוסיף צומת אחד לאשכול האדמין.

אם אתם צריכים אשכול אדמין עם N צמתים, אתם צריכים לוודא שבלוק ה-CIDR של ה-Pod גדול מספיק כדי לתמוך ב-N /24 בלוקים.

בטבלה הבאה מפורט המספר המקסימלי של הצמתים שנתמכים בגדלים שונים של בלוקים של Pod CIDR:

גודל חסימת ה-CIDR של ה-Pod המספר המקסימלי של צמתים שנתמכים
/18 64
/17 128
/16 256
/15 512

בלוק ה-CIDR של הפודים שמוגדר כברירת מחדל באשכול אדמין הוא 192.168.0.0/16, שתומך ב-256 צמתים.

באשכול אדמין עם 100 אשכולות משתמשים של kubeception HA, יש 3 צמתים של מישור הבקרה של אשכול האדמין ו-300 צמתים של מישור הבקרה של אשכולות המשתמשים. המספר הכולל של הצמתים הוא 303 (יותר מ-256). לכן, צריך לעדכן את בלוק ה-CIDR של ה-Pod ל-‎ /15 כדי לתמוך בעד 100 אשכולות משתמשים של kubeception עם זמינות גבוהה.

כדי להגדיר את בלוק ה-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 עוזרים לכם לעקוב אחרי המשאבים.

השימוש במעבד ובזיכרון של רכיבי הרישום ביומן והמעקב שנפרסו באשכול אדמין משתנה בהתאם למספר אשכולות המשתמשים של kubeception.

בטבלה הבאה מתואר כמות הזיכרון וה-CPU של צומת אשכול האדמין שנדרשת להפעלת מספר גדול של אשכולות משתמשים מסוג 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) של צומת באשכול אדמין זיכרון של צומת באשכול אדמין
‫0 עד 20 ‫4 מעבדים (CPU) ‫16GB
‫21 עד 100 ‫8 מעבדים (CPU) ‫16GB
101 עד 500 ‫16 מעבדים 32GB

לדוגמה, אם יש 3 צמתים של אשכול אדמין, ולכל אחד מהם יש 4 מעבדים וזיכרון של 16GB, אפשר להפעיל אשכול משתמשים אחד עם זמינות גבוהה עם 14 צמתים של עובדים. כדי ליצור יותר מ-20 אשכולות של משתמשים מתקדמים, כשבכל אשכול משתמשים יש יותר מ-10 צמתים, צריך קודם לשנות את הגודל של זיכרון הצומת באשכול האדמין מ-16GB ל-32GB.

GKE Hub

כברירת מחדל, אפשר לרשום עד 250 אשכולות עם חברות גלובלית לכל צי. כדי לרשום עוד אשכולות ב-GKE Hub, אפשר לשלוח בקשה להגדלת המכסה במסוף Google Cloud :

לדף Quotas

מידע נוסף על מכסות של אשכולות שמבוססות על הגדרות החברות זמין במאמר מכסות הקצאה.

הפעלת הרבה צמתים ו-pods באשכול משתמשים

כשמתכוננים להפעלת הרבה צמתים ותאים (pods) באשכול משתמשים, צריך לבצע את השלבים הבאים כשיוצרים את אשכול המשתמשים.

חסימת CIDR של ה-Pod באשכול המשתמשים

בלוק ה-CIDR של ה-Pod הוא בלוק ה-CIDR של כל ה-Pods באשכול משתמשים. ההגדרה מתבצעת דרך השדה network.podCIDR ב-user-cluster.yaml.

מתוך הטווח הזה, מוקצה לכל צומת בלוק קטן יותר מסוג ‎ /24. אם אתם צריכים אשכול עם N צמתים, אתם צריכים לוודא שהבלוק הזה גדול מספיק כדי לתמוך ב-N /24 בלוקים.

בטבלה הבאה מפורט המספר המקסימלי של הצמתים שנתמכים בגדלים שונים של בלוקים של Pod CIDR:

גודל חסימת ה-CIDR של ה-Pod המספר המקסימלי של צמתים שנתמכים
/18 64
/17 128
/16 256
/15 512

בלוק ה-CIDR של הפוד שמוגדר כברירת מחדל הוא 192.168.0.0/16, והוא תומך ב-256 צמתים. לדוגמה, כדי ליצור אשכול עם 500 צמתים, צריך לשנות את בלוק ה-CIDR של ה-Pod באשכול המשתמשים לשימוש בטווח ‎ /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 מעבדים ‫5GB
‫21 עד 75 ‫3 מעבדים ‫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, כמו prometheus-server ו-stackdriver-prometheus-sidecar, משתמשים במשאבי מעבד וזיכרון שונים בהתאם למספר הצמתים ומספר ה-Pods. לפני שמגדילים את קנה המידה של האשכול, מגדירים את בקשת המשאבים ואת המגבלה בהתאם לשימוש הממוצע המשוער ברכיבים האלה. בטבלה הבאה מוצגות הערכות לגבי כמות השימוש הממוצעת בכל רכיב:

מספר הצמתים שם הקונטיינר הערכת השימוש במעבד הערכת השימוש בזיכרון
‫0 pods/node ‫30 פודים/צומת ‫0 pods/node ‫30 פודים/צומת
‫3 עד 50 prometheus-server ‫100 מ' ‫390 מ' ‫650 מיליון ‫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 בהתאם לטבלה שלמעלה, ליצור מאגר צמתים כדי להתאים את הרכיבים, ואז להגדיל בהדרגה את האשכול לגודל גדול יותר.

כדי למנוע תזמון של פודים אחרים למאגר הצמתים, אפשר לבחור לשמור על מאגר צמתים בגודל מספיק רק לרכיבי הניטור והרישום. כדי לעשות זאת, צריך להוסיף את ההכתמות הבאות למאגר הצמתים:

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, זיכרון/מעבד של מופע וירטואלי ורישיונות.

רכיבי מערכת של התאמה אוטומטית לעומס (auto-scaling)

מערכת Google Distributed Cloud משנה את גודל הרכיבים באופן אוטומטי באשכולות המשתמשים בהתאם למספר הצמתים, בלי שתצטרכו לשנות את ההגדרות. אפשר להשתמש במידע שבקטע הזה לתכנון משאבים.

  • ‫Google Distributed Cloud מבצע באופן אוטומטי שינוי גודל אנכי על ידי שינוי הגודל של בקשות/מגבלות ה-CPU והזיכרון של רכיבי המערכת הבאים באמצעות addon-resizer:

    • ‫kube-state-metrics הוא פריסה שפועלת בצמתי עובדים באשכול, שמקשיבה לשרת ה-API של Kubernetes ומייצרת מדדים לגבי מצב האובייקטים. הבקשות והמגבלות של מעבד ה-CPU והזיכרון משתנות בהתאם למספר הצמתים.

      בטבלה הבאה מפורטים בקשות המשאבים והמגבלות שהוגדרו על ידי המערכת, בהתאם למספר הצמתים באשכול:

      מספר הצמתים בקשה/מגבלה משוערת1 של יחידת עיבוד מרכזית (CPU) (אלפית) בקשת זיכרון/מגבלה משוערת (Mi)1
      ‫3 עד 5 105 110
      ‫6 עד 500 ‫100 + num_nodes ‫100 + (2 * num_nodes)

      ‫1 יש מרווח של ‎+-5% ‎ כדי להפחית את מספר ההפעלות מחדש של הרכיבים במהלך שינוי הגודל.

      לדוגמה, באשכול עם 50 צמתים, בקשת המעבד והמגבלה שלו מוגדרות ל-150m/150m, ובקשת הזיכרון והמגבלה שלו מוגדרות ל-200Mi/200Mi. ב-cluster עם 250 צמתים, בקשת המעבד (CPU) והמגבלה שלו מוגדרות ל-350m/350m, ובקשת הזיכרון והמגבלה שלו מוגדרות ל-600Mi.

    • ‫metrics-server הוא פריסה שפועלת בצמתי עובדים באשכול, והוא משמש את צינורות העיבוד המובנים של Kubernetes להתאמה אוטומטית לעומס. הבקשה והמגבלות של המעבד (CPU) והזיכרון גדלות בהתאם למספר הצמתים.

  • ב-Google Distributed Cloud, מתבצעת התאמה אוטומטית לעומס (automatic scaling) אופקית גם באשכולות אדמין וגם באשכולות משתמשים, על ידי שינוי מספר העותקים של רכיבי המערכת הבאים:

    • ‫core-dns הוא פתרון ה-DNS שמשמש לזיהוי שירותים. היא פועלת כפריסת Deployment בצמתי worker באשכול משתמשים. ב-Google Distributed Cloud, מספר העותקים המשוכפלים משתנה באופן אוטומטי בהתאם למספר הצמתים וליבות המעבד באשכול. עם כל הוספה או מחיקה של 16 צמתים או 256 ליבות, מספר הרפליקות גדל או קטן ב-1. אם יש לכם אשכול של N צמתים ו-C ליבות, אתם יכולים לצפות ל-max(N/16, C/256) עותקים משוכפלים.

    • ‫calico-typha הוא רכיב לתמיכה בנטוורקינג של Pod. היא פועלת כפריסת Deployment בצמתי worker באשכול משתמשים. ב-Google Distributed Cloud, מספר העותקים המשוכפלים של calico-typha משתנה אוטומטית בהתאם למספר הצמתים באשכול:

      מספר הצמתים (N) מספר הרפליקות של Calico-Typha
      N = 1 1
      ‫1 < N < 200 2
      N >= 200 ‫3 או יותר

    • ‫Istio ingress-gateway הוא הרכיב לתמיכה ב-ingress של אשכולות, והוא פועל כ-Deployment בצמתי worker של אשכולות משתמשים. בהתאם לכמות התנועה ששער הכניסה מטפל בה, Google Distributed Cloud משתמש ב-Horizontal Pod Autoscaler כדי לשנות את מספר הרפליקות בהתאם לשימוש במעבד, עם מינימום של 2 רפליקות ומקסימום של 5 רפליקות.

    • שרת ה-proxy של רשת konnectivity‏ (KNP) מספק שרת proxy ברמת TCP ליציאה מצמתי מישור הבקרה של אשכול המשתמשים. הוא יוצר מנהור לתנועת יציאה של kube-apiserver של המשתמש, שמיועדת לצמתים של אשכול המשתמש. סוכן הקישוריות פועל כפריסה בצמתי העובדים של אשכול המשתמשים. ב-Google Distributed Cloud, מספר הרפליקות של סוכן הקישוריות משתנה אוטומטית בהתאם למספר הצמתים באשכול.

      מספר הצמתים (N) מספר העותקים המשוכפלים של סוכן הקישוריות
      ‫1 <= N <= 6 N
      ‫6 < N < 10 6
      ‫10 <= N < 100 8
      ‫N >= 100 ‫12 או יותר

שיטות מומלצות

בקטע הזה מתוארות שיטות מומלצות להרחבת המשאבים.

הגדלת האשכול בשלבים

יצירת צומת Kubernetes כוללת שיבוט של תבנית קובץ האימג' של מערכת ההפעלה של הצומת לקובץ דיסק חדש, שהיא פעולת vSphere שדורשת הרבה פעולות קלט/פלט. אין בידוד של קלט/פלט בין פעולת השיבוט לבין פעולות קלט/פלט של עומס העבודה. אם נוצרים יותר מדי צמתים בו-זמנית, פעולות השיבוט יימשכו זמן רב מדי, ויכול להיות שהן ישפיעו על הביצועים ועל היציבות של האשכול ועומסי העבודה הקיימים.

מוודאים שההגדלה של האשכול מתבצעת בשלבים, בהתאם למשאבי vSphere. לדוגמה, כדי לשנות את הגודל של אשכול מ-3 ל-500 צמתים, כדאי לשנות את הגודל בשלבים מ-150 ל-350 ל-500, כדי להפחית את העומס על תשתית vSphere.

אופטימיזציה של ביצועי קלט/פלט (I/O) בדיסק של etcd

‫etcd הוא מאגר של זוגות מפתח/ערך שמשמש כמאגר הגיבוי של Kubernetes לכל נתוני האשכול. הביצועים והיציבות שלו קריטיים לבריאות האשכול, והם רגישים לזמן האחזור של קלט/פלט (I/O) בדיסק וברשת.

  • כדי לשפר את ביצועי הקלט/פלט של מאגר הנתונים של vSphere שמשמש למכונות וירטואליות של מישור הבקרה, כדאי לפעול לפי ההמלצות הבאות:

  • זמן אחזור של כמה מאות אלפיות השנייה מצביע על צוואר בקבוק בקלט/פלט של הדיסק או הרשת, ויכול להוביל למצב לא תקין של האשכול. עוקבים אחרי מדדי השהייה של קלט/פלט ב-etcd ומגדירים ספי התראה עבורם:

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

אופטימיזציה של ביצועי קלט/פלט של דיסק האתחול של הצומת

‫Pods משתמשים באחסון זמני לפעולות פנימיות, כמו שמירת קבצים זמניים. האחסון הזמני נצרך על ידי השכבה שניתן לכתוב בה של הקונטיינר, ספריית היומנים ונפחי האחסון של emptyDir. אחסון זמני מגיע ממערכת הקבצים של הצומת, שמגובה על ידי דיסק האתחול של הצומת.

מכיוון שאין בידוד של קלט/פלט (I/O) באחסון בצמתי Kubernetes, אפליקציות שצורכות קלט/פלט גבוה במיוחד באחסון הזמני שלהן עלולות לגרום לחוסר יציבות בצומת על ידי מניעת משאבים מרכיבי מערכת כמו Kubelet והדמון של Docker.

מוודאים שמאפייני הביצועים של קלט/פלט במאגר הנתונים שבו מוקצים דיסקים של אתחול יכולים לספק את הביצועים הנכונים לשימוש באחסון זמני ולתנועת רישום ביומן של האפליקציה.

מעקב אחרי התנגשות משאבים פיזיים

חשוב להכיר את היחסים בין vCPU ל-pCPU ואת הקצאת יתר של זיכרון. יחס לא אופטימלי או תחרות על הזיכרון במארחים הפיזיים עלולים לגרום לירידה בביצועים של מכונה וירטואלית. מומלץ לעקוב אחרי ניצול המשאבים הפיזיים ברמת המארח ולהקצות מספיק משאבים להרצת אשכולות גדולים.