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

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

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

מהי מדרגיות?

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירה בין מאגרי צמתים בכמה אזורים או באזור אחד

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

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

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

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

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

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

בחירת אזורי AI

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

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

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

  • כדי להשתמש באזור AI עם אשכולות GKE קיימים, מישור הבקרה צריך להריץ את גרסה ‎1.36.4-gke.1495002 ואילך, או את גרסה ‎1.37.1-gke.1552000 ואילך. הגרסאות האלה מאפשרות למישור הבקרה לזהות את האזור ולרשום צמתים. אם במישור הבקרה פועלת גרסה 1.35 או גרסה קודמת, או גרסה שקודמת לגרסאות המינימליות האלה, שדרגו את מישור הבקרה לפני שאתם יוצרים מאגרי צמתים באזור ה-AI. אם אי אפשר לשדרג, פנו אל Cloud Customer Care.
  • אזורי AI מופרדים פיזית מאזורים רגילים כדי לספק שטח אחסון וחשמל נוספים. ההפרדה הזו עלולה לגרום לזמן אחזור ארוך יותר, שבדרך כלל אפשר לסבול בעומסי עבודה של AI/ML.
  • לאזורי AI יש סיומת עם הסימון ai. לדוגמה, אזור AI ב-us-central1 נקרא us-central1-ai1a.
  • בשלב הזה יש תמיכה רק במכונות וירטואליות של TPU.
  • מישור הבקרה של האשכול פועל באזור סטנדרטי אחד או יותר באותו אזור שבו נמצא אזור ה-AI.

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

    • כבר פועלים עומסי עבודה אחרים שמשתמשים ב-TPU VM באותו אזור.
    • המכונות הווירטואליות שהן לא 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-native. הוא פועל על ידי הוספת מסלול בהתאמה אישית חדש לטבלת הניתוב ברשת ה-VPC לכל צומת חדש.

גודל האשכול

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

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

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

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

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

אם אתם צריכים להגדיל את המכסה, פנו לצוות המכירות של Google Cloud כדי להגדיל את המגבלה.

DNS

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

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

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

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

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

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

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

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

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

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

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

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

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

ב- Google Cloud, סוג המכונה ומספר הליבות שהוקצו למכונה קובעים את קיבולת הרשת שלה. רוחב הפס המקסימלי לתעבורת נתונים יוצאת נע בין ‎1 Gbps ל-‎32 Gbps, ורוחב הפס המקסימלי לתעבורת נתונים יוצאת במכונות e2-medium-2 שמוגדרות כברירת מחדל הוא ‎2 Gbps. למידע נוסף על מגבלות רוחב הפס, קראו את המאמר מכונות עם ליבה משותפת (shared-core).

‫IOPS וקצב העברת הנתונים בדיסק

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

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

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

בעומסי עבודה שדורשים קיבולת גבוהה או מספר גדול של דיסקים, צריך להביא בחשבון את המגבלות על מספר הדיסקים הקבועים שאפשר לצרף למכונה וירטואלית אחת. במכונות וירטואליות רגילות, המגבלה היא 128 דיסקים בגודל כולל של 64TB, ובמכונות וירטואליות עם ליבת מעבד משותפת המגבלה היא 16 דיסקים קבועים בגודל כולל של 3TB. המגבלה הזו נאכפת על ידי Google Cloud ולא על ידי 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 עלול להעמיס על מישור הבקרה או לגרום לוויסות קצב (throttling) משמעותי של הבקשות האלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה השלב הבא?