שיטות מומלצות למדרגיות ב-GKE

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

לסקירה כללית של כל השיטות המומלצות ל-GKE, קראו את המאמר שיטות מומלצות ל-GKE.

מהי מדרגיות?

באשכול Kubernetes, יכולת ההתאמה (scalability) מתייחסת ליכולת של האשכול לגדול תוך שמירה על היעדים למדידת רמת השירות (SLO) שלו. ל-Kubernetes יש גם קבוצה משלו של יעדי זמינות (SLO)

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

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

בחירת מישור בקרה אזורי או תחום

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

אם משדרגים אשכול אזורי, המכונה הווירטואלית של רמת הבקרה מושבתת במהלך השדרוג, ולכן ה-API של Kubernetes לא זמין עד שהשדרוג מסתיים.

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

עם זאת, יש חסרונות מסוימים לאשכולות אזוריים עם זמינות גבוהה יותר:

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

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

בגלל ההבדלים האלה, יש תרחישי שימוש שונים לאשכולות אזוריים ולאשכולות בתחום ספציפי:

  • אשכולות אזוריים מתאימים ליצירה או לשדרוג של אשכולות במהירות, כשהזמינות פחות חשובה.
  • כדאי להשתמש באשכולות אזוריים כשהזמינות חשובה יותר מהגמישות.

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

בחירה של מאגרי צמתים מרובי אזורים או מאגרי צמתים של אזור יחיד

כדי להשיג זמינות גבוהה, צריך לפרוס את מישור הבקרה של Kubernetes ואת הצמתים שלו באזורים שונים. ב-GKE יש שני סוגים של מאגרי צמתים: מאגר צמתים באזור יחיד ומאגר צמתים בכמה אזורים.

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

אם כל הצמתים נמצאים באותו אזור, לא תוכלו לתזמן Pods אם לא תהיה גישה לאזור הזה. יש כמה חסרונות לשימוש במאגרי צמתים בכמה אזורים:

  • יחידות GPU זמינות רק באזורים ספציפיים. יכול להיות שלא תוכלו לקבל אותם בכל האזורים במחוז.

  • זמן הטעינה הלוך ושוב בין אזורים באותו אזור עשוי להיות ארוך יותר מזמן הטעינה הלוך ושוב בין משאבים באותו אזור. ההבדל לא אמור להיות משמעותי ברוב עומסי העבודה.

  • המחיר של תעבורת יציאה בין אזורים באותו אזור זמין בדף התמחור של Compute Engine.

בחירת אזורי AI

אזורי AI הם אזורים ייעודיים שמשמשים לעומסי עבודה של אימון והסקת מסקנות של AI/ML. באזורים האלה יש קיבולת משמעותית של מאיצי למידת מכונה. מידע נוסף זמין במאמר בנושא אזורים עם AI.

במסמך הזה ובמסמכי התיעוד של GKE, המונחים "אזורים רגילים" או "אזורים" מתייחסים לאזורים שאינם אזורי AI בתוך אזור Cloud de Confiance by S3NS .

לפני שאתם משתמשים באזור AI ב-GKE, כדאי להביא בחשבון את המאפיינים הבאים:

  • אזורי AI מופרדים פיזית מאזורים רגילים כדי לספק נפח אחסון וחשמל נוספים. ההפרדה הזו עלולה לגרום לזמן אחזור ארוך יותר, שבדרך כלל אפשר לסבול בעומסי עבודה של AI/ML.
  • לאזורי AI יש סיומת עם הסימון ai. לדוגמה, אזור AI באזור us-central1 נקרא us-central1-ai1a.
  • בשלב הזה יש תמיכה רק במכונות וירטואליות של TPU.
  • מישור הבקרה של האשכול פועל באזור סטנדרטי אחד או יותר באותו אזור שבו נמצא אזור ה-AI.

  • אפשר להריץ מכונות וירטואליות בלי יחידות TPU מצורפות באזור AI רק אם מתקיימות הדרישות הבאות:

    • כבר מריצים עומסי עבודה אחרים שמשתמשים במכונות וירטואליות של TPU באותו אזור.
    • המכונות הווירטואליות שהן לא TPU VM הן VM במודל Spot, שקשורות למקום שמור או שהן חלק ממאגר צמתים עם יחס ספציפי בין המאיץ למכונה הווירטואלית לשימוש כללי.

  • אזורי AI חולקים רכיבים, כמו חיבורי רשת ופריסות תוכנה, עם אזורים רגילים שיש להם את אותו סיומת באותו אזור. לעומסי עבודה של זמינות גבוהה, מומלץ להשתמש באזורים שונים. לדוגמה, אל תשתמשו גם ב-us-central1-ai1a וגם ב-us-central1-a כדי להשיג זמינות גבוהה.

כברירת מחדל, GKE לא פורס את עומסי העבודה שלכם באזורי AI. כדי להשתמש באזור AI, צריך להגדיר אחת מהאפשרויות הבאות:

  • ‫(מומלץ) ComputeClasses: הגדרת העדיפות הגבוהה ביותר לבקשת יחידות TPU על פי דרישה באזור AI. בעזרת ComputeClasses אפשר להגדיר רשימה עם עדיפות של תצורות חומרה לעומסי העבודה. לדוגמה, ראו מידע על ComputeClasses.
  • הקצאת צמתים אוטומטית (NAP): משתמשים ב-nodeSelector או ב-nodeAffinity במפרט של ה-Pod כדי להורות ל-NAP ליצור מאגר צמתים באזור ה-AI. אם עומס העבודה שלכם לא מיועד באופן מפורש לאזור AI, הקצאה אוטומטית של צמתים תתבסס רק על אזורים רגילים או על אזורים מ---autoprovisioning-locations כשיוצרים מאגרי צמתים חדשים. ההגדרה הזו עוזרת לוודא שעומסי עבודה שלא מריצים מודלים של AI או למידת מכונה יישארו באזורים רגילים, אלא אם תגדירו אחרת באופן מפורש. דוגמה למניפסט שמשתמש ב-nodeSelector, אפשר לראות במאמר הגדרת אזורי ברירת המחדל לצמתים שנוצרו אוטומטית.
  • ‫GKE Standard: אם אתם מנהלים ישירות את מאגרי הצמתים, השתמשו באזור AI בדגל --node-locations כשאתם יוצרים מאגר צמתים. לדוגמה, ראו פריסת עומסי עבודה של TPU ב-GKE Standard.

שיטות מומלצות להרחבת הפעילות

תשתית בסיסית

עומסי עבודה ב-Kubernetes דורשים רשת, מחשוב ואחסון. צריך לספק מספיק מעבד (CPU) וזיכרון כדי להריץ Pods. עם זאת, יש עוד פרמטרים של התשתית הבסיסית שיכולים להשפיע על הביצועים ועל יכולת ההתאמה לעומס של אשכול GKE.

נטוורקינג באשכול

השימוש באשכול המותאם ל-VPC הוא ברירת המחדל של הרשת והאפשרות המומלצת להגדרה של אשכולות GKE חדשים. אשכולות המותאמים ל-VPC מאפשרים עומסי עבודה גדולים יותר, מספר גדול יותר של צמתים ויתרונות נוספים.

במצב הזה, לרשת ה-VPC יש טווח משני לכל כתובות ה-IP של ה-Pod. לאחר מכן, כל צומת מקבל פרוסה מהטווח המשני לכתובות ה-IP של ה-Pod שלו. כך רשת ה-VPC יכולה להבין באופן מקורי איך לנתב תנועה ל-Pods בלי להסתמך על מסלולים בהתאמה אישית. ברשת VPC אחת יכולות להיות עד 15,000 מכונות וירטואליות.

גישה אחרת, שהוצאה משימוש ותומכת ב-1,500 צמתים לכל היותר, היא להשתמש באשכול מבוסס-נתיבים. אשכול מבוסס-נתיבים לא מתאים לעומסי עבודה גדולים. הוא צורך את מכסת המסלולים של VPC וחסרים בו יתרונות אחרים של רשתות מקוריות ל-VPC. הוא פועל על ידי הוספת מסלול מותאם אישית חדש לטבלת הניתוב ברשת ה-VPC לכל צומת חדש.

גודל האשכול

אשכולות GKE Standard תומכים בהרחבה של עד 65,000 צמתים. בהתאם למספר צמתי היעד, יש דרישות תשתית ספציפיות, ויכול להיות שתצטרכו לפנות ל-Cloud Customer Care. מידע מפורט זמין במאמר בנושא מגבלות ודרישות לגבי גודל האשכול.

איזון עומסים באשכול

‫GKE Ingress ו-Cloud Load Balancing מגדירים ופורסים מאזני עומסים כדי לחשוף עומסי עבודה של Kubernetes מחוץ לאשכול וגם לאינטרנט הציבורי. בקרי ה-Ingress והשירות של GKE פורסים אובייקטים כמו כללי העברה, מפות URL, שירותים לקצה העורפי, קבוצות של נקודות קצה ברשת ועוד, בשם עומסי העבודה של GKE. לכל אחד מהמשאבים האלה יש מכסות ומגבלות מובנות, והמגבלות האלה חלות גם ב-GKE. כשמשאב מסוים של Cloud Load Balancing מגיע למכסה שלו, הוא מונע פריסה תקינה של Ingress או Service מסוימים, ושגיאות יופיעו באירועים של המשאב.

בטבלה הבאה מתוארות מגבלות ההתאמה לעומס כשמשתמשים ב-Ingress ובשירותים של GKE:

מאזן עומסים מגבלת צמתים לכל אשכול
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי
מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי ‫1,000 צמתים לכל אזור
מאזן עומסים חיצוני של אפליקציות (ALB)
מאזן עומסים פנימי של אפליקציות (ALB) אין מגבלה על מספר הצמתים

אם אתם צריכים להגדיל את המכסה, פנו לצוות המכירות של Cloud de Confiance by S3NS .

DNS

זיהוי השירותים ב-GKE מתבצע באמצעות kube-dns, שהוא משאב מרכזי שמספק פענוח DNS ל-Pods שפועלים בתוך האשכול. זה יכול להפוך לצוואר בקבוק באשכולות גדולים מאוד או בעומסי עבודה עם עומס בקשות גבוה. ‫GKE מבצע התאמה אוטומטית לעומס (autoscaling) של kube-dns בהתאם לגודל האשכול כדי להגדיל את הקיבולת שלו. אם הקיבולת הזו עדיין לא מספיקה, GKE מציע פתרון מקומי מבוזר של שאילתות DNS בכל צומת באמצעות NodeLocal DNSCache. הוא מספק מטמון DNS מקומי בכל צומת GKE שעונה על שאילתות באופן מקומי, מפזר את העומס ומספק זמני תגובה מהירים יותר.

ניהול כתובות IP באשכולות המותאמים ל-VPC

באשכול המותאם ל-VPC נעשה שימוש בשלושה טווחי כתובות IP:

  • טווח ראשי של רשת המשנה של הצומת: ברירת המחדל היא ‎ /20 (4,092 כתובות IP).
  • טווח משני לרשת המשנה של ה-Pod: ברירת המחדל היא ‎ /14 (262,144 כתובות IP). עם זאת, אפשר להגדיר את רשת המשנה של ה-Pod.
  • טווח משני לתת-רשת של שירות: ברירת המחדל היא ‎ /20 (4,096 כתובות). עם זאת, אי אפשר לשנות את הטווח הזה אחרי שיוצרים את רשת המשנה של השירות.

מידע נוסף זמין במאמר טווחי כתובות IP לאשכולות המותאמים ל-VPC.

הגבלות והמלצות לגבי כתובות IP:

  • מגבלת הצמתים: מגבלת הצמתים נקבעת לפי כתובות ה-IP הראשיות וכתובות ה-IP של Pod לכל צומת. צריכות להיות מספיק כתובות בטווח כתובות ה-IP של הצומת ושל ה-Pod כדי להקצות צומת חדש. כברירת מחדל, אפשר ליצור רק 1,024 צמתים בגלל מגבלות של כתובות IP של Pod.
  • מגבלת ה-Pods לכל צומת: כברירת מחדל, מגבלת ה-Pods לכל צומת היא 110 Pods. עם זאת, אפשר להגדיר טווחי CIDR קטנים יותר של Pods כדי להשתמש ביעילות בפחות Pods לכל צומת.
  • התאמה לשימוש מעבר ל-RFC 1918: אם אתם צריכים יותר כתובות IP מאלה שזמינות במרחב הפרטי שמוגדר על ידי RFC 1918, מומלץ להשתמש בכתובות פרטיות שאינן RFC 1918 או בכתובות IP פרטיות לשימוש ציבורי כדי לקבל גמישות נוספת.
  • טווח כתובות IP משני לשירות ול-Pod: כברירת מחדל, אפשר להגדיר 4,096 שירותים. עם זאת, אפשר להגדיר עוד שירותים על ידי בחירת טווח רשת המשנה של השירות. אי אפשר לשנות טווחים משניים אחרי שיוצרים אותם. כשיוצרים אשכול, חשוב לוודא שבוחרים טווחים גדולים מספיק כדי להתאים לגידול הצפוי. עם זאת, אפשר להוסיף עוד כתובות IP לפודים מאוחר יותר באמצעות CIDR רב-פודים לא רציף.

למידע נוסף, קראו את המאמרים הבאים:

הגדרת צמתים לשיפור הביצועים

צמתים של GKE הם מכונות וירטואליות Cloud de Confiance רגילות. חלק מהפרמטרים שלהם, כמו מספר הליבות או גודל הדיסק, יכולים להשפיע על הביצועים של אשכולות GKE.

קיצור זמני האתחול של Pod

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

תנועה יוצאת (egress)

ב- Cloud de Confiance, סוג המכונה ומספר ליבות המעבד שהוקצו למופע קובעים את קיבולת הרשת שלו. רוחב הפס המקסימלי לתעבורת נתונים יוצאת נע בין ‎1 Gbps ל-‎32 Gbps, ורוחב הפס המקסימלי לתעבורת נתונים יוצאת במכונות e2-medium-2 שמוגדרות כברירת מחדל הוא ‎2 Gbps. פרטים על מגבלות רוחב הפס זמינים במאמר בנושא סוגי מכונות עם ליבות משותפות.

IOPS ותפוקת הדיסק

ב- Cloud de Confiance, הגודל של הדיסקים לאחסון מתמיד קובע את ה-IOPS ואת קצב הנתונים של הדיסק. בדרך כלל, GKE משתמש ב-Persistent Disk כדיסקי אתחול וכדי לגבות את נפחי האחסון המתמיד של Kubernetes. הגדלת גודל הדיסק מגדילה את קצב ה-IOPS ואת קצב העברת הנתונים, עד מגבלות מסוימות.

כל פעולת כתיבה בדיסק לאחסון מתמיד תורמת למגבלת תעבורת הנתונים היוצאת המצטברת ברשת של המכונה הווירטואלית. לכן, ביצועי ה-IOPS של הדיסקים, במיוחד של כונני SSD, תלויים גם במספר מעבדי ה-vCPU במכונה, בנוסף לגודל הדיסק. למכונות וירטואליות עם פחות ליבות יש מגבלות נמוכות יותר של IOPS בכתיבה, בגלל מגבלות של תעבורת נתונים יוצאת ברשת על קצב העברת הנתונים בכתיבה.

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

עומסי עבודה שדורשים קיבולת גבוהה או מספר גדול של דיסקים צריכים להתחשב במגבלות של מספר ה-PD שאפשר לצרף למכונה וירטואלית אחת. במכונות וירטואליות רגילות, המגבלה היא 128 דיסקים בגודל כולל של 64TB, ובמכונות וירטואליות עם ליבת מעבד משותפת המגבלה היא 16 דיסקים קבועים בגודל כולל של 3TB.המגבלה הזו נאכפת על ידי Cloud de Confiance ולא על ידי Kubernetes.

מעקב אחרי מדדים של מישור הבקרה

אפשר להשתמש במדדי מישור הבקרה שזמינים כדי להגדיר את מרכזי הבקרה של המעקב. אתם יכולים להשתמש במדדים של מישור הבקרה כדי לבדוק את תקינות האשכול, את התוצאות של שינויים בהגדרות האשכול (לדוגמה, פריסת עומסי עבודה נוספים או רכיבים של צד שלישי) או כשאתם פותרים בעיות.

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

זמן האחזור של Kubernetes API יכול להתארך גם בגלל תגובות איטיות מרכיבי webhook של אישור כניסה של צד שלישי. אתם יכולים להשתמש במדדים כדי למדוד את זמן האחזור של ה-webhooks ולזהות בעיות נפוצות כאלה.

הגבול העליון המומלץ לקריאה של משאב יחיד, כמו GET,‏ POST או PATCH, הוא שנייה אחת. הגבול העליון המומלץ לקריאות LIST ברמת מרחב השמות וברמת האשכול הוא 30 שניות. הציפיות לגבול העליון נקבעות על ידי יעדי SLO שמוגדרים על ידי קהילת הקוד הפתוח של Kubernetes. מידע נוסף זמין במאמר פרטים על מדדי רמת השירות (SLI) ויעדי רמת השירות (SLO) של זמן האחזור של קריאות ל-API.

שיטות מומלצות למפתחי Kubernetes

שימוש בתבנית של רשימה וצפייה במקום רישום תקופתי

כמפתחי Kubernetes, יכול להיות שתצטרכו ליצור רכיב עם הדרישות הבאות:

  • הרכיב שלכם צריך לאחזר את הרשימה של אובייקטים מסוימים של Kubernetes מדי פעם.
  • הרכיב צריך לפעול בכמה מקרים (במקרה של DaemonSet, אפילו בכל צומת).

רכיב כזה יכול ליצור עומסים פתאומיים ב-kube-apiserver, גם אם המצב של האובייקטים שנשלפים מדי פעם לא משתנה.

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

כדי לשפר את הרכיב, אפשר להגדיר את הפרמטר resourceVersion=0 בקריאות LIST. כך kube-apiserver יכול להשתמש במטמון של אובייקטים בזיכרון, ולהפחית את תדירות האינטראקציה של שרת ה-API של Kubernetes עם ה-API של etcd, וגם את כל העיבוד שקשור אליו.

מומלץ מאוד להימנע מקריאות LIST חוזרות ולהחליף אותן בתבנית list and watch. מציגים את רשימת האובייקטים פעם אחת ואז משתמשים ב-Watch API כדי לקבל שינויים מצטברים במצב. הגישה הזו מקצרת את זמן העיבוד ומצמצמת את נפח התנועה בהשוואה לקריאות LIST תקופתיות. אם האובייקטים לא משתנים, לא נוצר עומס נוסף.

אם אתם משתמשים בשפת Go, כדאי לעיין ב-SharedInformer וב-SharedInformerFactory כדי לראות חבילות Go שמיישמות את התבנית הזו.

הגבלת תנועה מיותרת שנוצרת על ידי צפיות ורשימות

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

אלה השיטות המומלצות:

  • צמצום העיבוד והתנועה המיותרים שנוצרים על ידי צפיות וקריאות LIST.
  • מומלץ להימנע מיצירת צפיות שצופות באובייקטים שמשתנים לעיתים קרובות ממספר מקומות (לדוגמה, DaemonSets).
  • (מומלץ מאוד) יוצרים בקר מרכזי שעוקב אחרי הנתונים הנדרשים ומעבד אותם בצומת יחיד.
  • לצפות רק בקבוצת משנה של האובייקטים, לדוגמה, kubelet בכל צומת צופה רק בתרמילים שמתוזמנים באותו צומת.
  • מומלץ להימנע מפריסת רכיבים או תוספים של צד שלישי שיכולים להשפיע על ביצועי האשכול על ידי ביצוע נפח גבוה של קריאות watch או LIST.

שימוש בעדכונים בהדרגה (rolling) עם DaemonSets כדי למנוע עליות פתאומיות בתנועה

כשיוצרים DaemonSet באשכול, הוא מתזמן פוד חדש בכל צומת באופן מיידי. אם כל ה-Pods החדשים האלה מתחברים לאותה נקודת קצה ברשת, הבקשות האלה מתרחשות בו-זמנית, מה שיוצר עומס גבוה על המארח המטורגט. כדי למנוע את זה, מגדירים את ה-DaemonSets עם עדכונים בהדרגה (rolling) עם פודים מוגבלים של maxSurge.

הגבלת הגודל של מניפסט האובייקטים של Kubernetes

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

‫Kubernetes מאחסן מניפסטים של משאבים במסד נתונים שהוא מאגר של מפתחות וערכים. המניפסט כולו נשלח בכל פעם שהמשאב מאוחזר, כולל כשמשתמשים בתבנית list ו-watch.

אלה המגבלות על גודל המניפסט:

  • הגודל המקסימלי של כל מניפסט אובייקט: כ-1.5 MiB.
  • המכסה הכוללת לכל אובייקטי ה-API של Kubernetes באשכול: גודל המכסה שהוגדרה מראש הוא 6GiB. הוא כולל יומן שינויים עם כל העדכונים לכל האובייקטים ב-150 השניות האחרונות של ההיסטוריה של האשכול.
  • ביצועים של מישור הבקרה בתקופות של עומס תעבורת נתונים גבוה: ככל שהמניפסט גדול יותר, העומס על שרת ה-API גדל.

כשמדובר באובייקטים בודדים שמעובדים לעיתים רחוקות, גודל המניפסט בדרך כלל לא מהווה בעיה כל עוד הוא קטן מ-1.5MiB. עם זאת, אם גודל המניפסט גדול מ-10 KiB עבור אובייקטים רבים שעוברים עיבוד בתדירות גבוהה – כמו פודים בעומסי עבודה גדולים מאוד – יכול להיות שזמן האחזור של קריאות ה-API יתארך והביצועים הכוללים ירדו. במיוחד רשימות וצפיות יכולות להיות מושפעות באופן משמעותי מגודל גדול של קובץ המניפסט. יכול להיות שיהיו גם בעיות במכסה של מסד הנתונים של מצב האשכול, כי מספר הגרסאות ב-150 השניות האחרונות יכול להצטבר במהירות בתקופות של תנועה גבוהה בשרת ה-API.

כדי להקטין את גודל המניפסט של pod, אפשר להשתמש ב-ConfigMaps של Kubernetes כדי לאחסן חלק מההגדרות, במיוחד את החלק שמשותף לכמה pods באשכול. לדוגמה, משתני סביבה משותפים בדרך כלל לכל ה-Pods בעומס עבודה.

שימו לב שאפשר להיתקל בבעיות דומות גם באובייקטים של ConfigMap אם יש הרבה מהם, אם הם גדולים ואם הם מעובדים בתדירות גבוהה כמו הפודים. חילוץ חלק מההגדרות האישיות שימושי במיוחד כשהוא מפחית את תנועת הגולשים הכוללת.

השבתת הטעינה האוטומטית של חשבון השירות שמוגדר כברירת מחדל

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

כשיוצרים Pod בלי לציין חשבון שירות, Kubernetes מבצע אוטומטית את הפעולות הבאות:

  • הקצאת חשבון השירות שמוגדר כברירת מחדל ל-Pod.
  • טעינת פרטי כניסה לחשבון השירות כסוד ל-Pod.
  • לכל Secret שמוטמע, ה-kubelet יוצר watch כדי לעקוב אחרי שינויים ב-Secret בכל צומת.

במקרים של אשכולות גדולים, הפעולות האלה מייצגות אלפי צפיות מיותרות, שיכולות להעמיס עומס משמעותי על kube-apiserver.

שימוש במאגר אחסון לפרוטוקולים במקום ב-JSON לבקשות API

כדאי להשתמש ב-מאגר אחסון לפרוטוקולים כשמטמיעים רכיבים בעלי יכולת הרחבה גבוהה, כפי שמתואר במאמר Kubernetes API Concepts.

‫Kubernetes API בארכיטקטורת REST תומך ב-JSON ובמאגרי אחסון לפרוטוקולים כפורמט לסריאליזציה של אובייקטים. כברירת מחדל נעשה שימוש ב-JSON, אבל מאגרי אחסון לפרוטוקולים יעילים יותר לביצועים בקנה מידה גדול, כי הם דורשים פחות עיבוד אינטנסיבי של המעבד (CPU) ושולחים פחות נתונים ברשת. התקורה שקשורה לעיבוד של JSON עלולה לגרום לפסק זמן כשמציגים נתונים בגודל גדול.

מה השלב הבא?