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

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

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

מהי מדרגיות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירת אזורי AI

אזורי AI הם אזורים מיוחדים שמשמשים לאימון AI/ML ולעומסי עבודה של הסקת מסקנות. האזורים האלה מספקים קיבולת משמעותית של מאיצי 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 באותו אזור.
    • מכונות ה-VM שאינן TPU הן מכונות VM במודל 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/ML יישארו באזורים רגילים, אלא אם תגדירו אחרת באופן מפורש. דוגמה למניפסט שמשתמש ב-nodeSelector מופיעה במאמר הגדרת אזורי ברירת המחדל לצמתים שנוצרו אוטומטית.
  • ‫GKE Standard: אם אתם מנהלים ישירות את מאגרי הצמתים, השתמשו באזור AI בדגל --node-locations כשאתם יוצרים מאגר צמתים. לדוגמה, אפשר לעיין במאמר בנושא פריסת עומסי עבודה של TPU ב-GKE Standard.

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

תשתית בסיסית

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

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

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

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

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

גודל האשכול

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

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

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

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

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

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

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

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

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

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

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

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

תעבורת נתונים יוצאת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה השלב הבא?