תכנון מדרגיות

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

מהי מדרגיות?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירת אזורי AI

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

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

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

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

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

  • אזורי 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 לכל צומת חדש.

גודל האשכול

בקטעי קוד עם יותר מ-5,000 צמתים צריך להשתמש ב-Private Service Connect. ‫Private Service Connect מחבר באופן פרטי בין הצמתים לבין מישור הבקרה, ומציע אבטחה וביצועים טובים יותר ברשת.

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

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

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

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

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

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

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

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

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

תנועת גולשים יוצאת

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

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

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

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

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

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

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

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

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

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

הגבול העליון המומלץ לקריאה של משאב יחיד, כמו GET,‏ POST או PATCH, הוא שנייה אחת. הגבול העליון המומלץ לקריאות LIST בהיקף של מרחב שמות ובהיקף של אשכול הוא 30 שניות. הציפיות לגבי הגבול העליון מוגדרות על ידי הסכמי רמת שירות (SLO) שהוגדרו על ידי קהילת הקוד הפתוח של 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 משתמשת באופן פנימי בצפיות כדי לשלוח התראות על עדכוני אובייקטים. גם אם שעונים דורשים הרבה פחות משאבים מאשר קריאות LIST תקופתיות, העיבוד של שעונים באשכולות גדולים יכול לתפוס חלק משמעותי מהמשאבים של האשכול ולהשפיע על הביצועים שלו. ההשפעה השלילית הכי גדולה נוצרת כשיוצרים שעונים שמתבוננים באובייקטים שמשתנים לעיתים קרובות מכמה מקומות. לדוגמה, על ידי צפייה בנתונים לגבי כל ה-Pods מרכיב שפועל בכל הצמתים. אם תתקינו קוד או תוספים של צד שלישי באשכול, הם יוכלו ליצור שעונים כאלה מתחת לפני השטח.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה השלב הבא?