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

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

לסקירה מרוכזת של כל השיטות המומלצות ל-GKE, אפשר לעיין במאמר שיטות מומלצות ל-GKE.

מהי מדרגיות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירת אזורי AI

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

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

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

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

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

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

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

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

  • ‫(מומלץ) ComputeClasses: מגדירים את העדיפות הכי גבוהה לבקשת TPU על פי דרישה באזור AI. בעזרת ComputeClasses אתם יכולים להגדיר רשימה של הגדרות חומרה לעומסי העבודה שלכם לפי סדר עדיפויות. לדוגמה, ראו מידע על ComputeClasses.
  • Node auto-provisioning: use a nodeSelector or nodeAffinity in your Pod specification to instruct node auto-provisioning to create a node pool in the AI zone. אם עומס העבודה לא מטרגט באופן מפורש אזור 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 יכולה להבין באופן מובנה איך לנתב תנועה לקבוצות Pod בלי להסתמך על מסלולים מותאמים אישית. ברשת 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) אין מגבלת צמתים

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

DNS

זיהוי שירותים ב-GKE מתבצע באמצעות kube-dns, שהוא משאב מרכזי שמספק פענוח DNS לקבוצות Pod שפועלות בתוך האשכול. זה יכול להפוך לצוואר בקבוק באשכולות גדולים מאוד או בעומסי עבודה עם עומס בקשות גבוה. ‫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 קטן יותר של Pod כדי להשתמש ביעילות בפחות Pods לכל צומת.
  • התאמה לשימוש מעבר ל-RFC 1918: אם אתם צריכים יותר כתובות IP מאלה שזמינות במרחב הפרטי שמוגדר על ידי RFC 1918, מומלץ להשתמש בכתובות פרטיות שאינן RFC 1918 או בכתובות IP פרטיות לשימוש ציבורי כדי לקבל גמישות נוספת.
  • טווח כתובות IP משני לשירות ול-Pod: כברירת מחדל, אפשר להגדיר 4,096 שירותים. עם זאת, אפשר להגדיר עוד שירותים על ידי בחירת טווח רשת המשנה של השירות. אי אפשר לשנות טווחים משניים אחרי היצירה. כשיוצרים אשכול, חשוב לוודא שבוחרים טווחים גדולים מספיק כדי להתאים לגידול הצפוי. עם זאת, בהמשך תוכלו להוסיף עוד כתובות IP לפודים באמצעות CIDR מרובה פודים לא רציף.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לשפר את הרכיב, אפשר להגדיר resourceVersion=0 parameter בקריאות 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 מאחסן מניפסטים של משאבים במסד נתונים שהוא מאגר של זוגות מפתח/ערך. המניפסט כולו נשלח בכל פעם שהמשאב מאוחזר, כולל כשמשתמשים בתבנית של רשימה וצפייה.

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

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

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

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

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

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

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

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

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

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

שימוש ב-Protocol buffers במקום ב-JSON לבקשות API

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

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

מה השלב הבא?