סקירה קצרה של הבעיה  יום אחד, במהלך עדכון מתוכנן של cluster k8s, גילינו שכמעט כל ה-POD שלנו (כ-500 מתוך 1,000) בצמתים חדשים לא הצליחו להתחיל, והדקות הפכו במהירות לשעות. מחפשים אותנו באופן פעיל אחר הסיבה לשורש, אך לאחר שלוש שעות, ה-PODS עדיין היו בסטטוס   .  ContainerCreating  למרבה המזל, זו לא הייתה סביבת הפרוד וחלון התחזוקה נקבע לסוף השבוע. היה לנו זמן לחקור את הנושא ללא כל לחץ.  היכן כדאי להתחיל את החיפוש אחר סיבת השורש? האם תרצה ללמוד עוד על הפתרון שמצאנו? התחברו ותהנו!  פרטים נוספים על הבעיה  הבעיה הייתה שהיו לנו מספר גדול של תמונות docker שצריך למשוך ולהתחיל בכל צומת באשכול בו זמנית. הסיבה לכך היא שמשיכות מרובות של תמונת docker בו-זמנית על צומת בודד יכולות להוביל לניצול גבוה של דיסקים וזמני התחלה קרים מוארכים.  מעת לעת, תהליך התקליטור לוקח עד 3 שעות כדי למשוך את התמונות. עם זאת, הפעם זה היה תקוע לחלוטין, כי כמות ה-PODS במהלך שדרוג ה-EKS (משולב, כאשר אנו מחליפים את כל הצמתים באשכול) הייתה גבוהה מדי.  כל האפליקציות שלנו חיות ב-k8s (מבוסס   ). כדי לחסוך בעלויות שלנו עבור DEV env, אנו משתמשים במופעים נקודתיים. EKS  אנו משתמשים בתמונת   עבור הצמתים. AmazonLinux2  יש לנו מספר רב של   (FBs) בסביבת הפיתוח שנפרסים ברציפות באשכול Kubernetes שלנו. לכל FB יש סט יישומים משלו, ולכל אפליקציה יש סט תלות משלו (בתוך תמונה). ענפי תכונה  בפרויקט שלנו, כמעט 200 אפליקציות והמספר הזה הולך וגדל. כל אפליקציה משתמשת באחת מ-7 תמונות העגינה הבסיסיות בגודל של ~2 GB. הגודל המקסימלי הכולל של התמונה המאוחסנת בארכיון (ב-   ) הוא כ-3 GB. ECR  כל התמונות מאוחסנות ב- Amazon Elastic Container Registry (ECR).  אנו משתמשים בסוג ברירת המחדל של gp3 EBS עבור הצמתים.   בעיות שהתמודדו    הפעלת פוד חדש עם תמונה חדשה עשויה להימשך יותר משעה, במיוחד כאשר מספר תמונות נמשכות במקביל על צומת בודד. זמן התחלה קרה מורחב:      תכופות או נתקעות במצבי   , מה שמצביע על בעיות עם משיכת תמונה. שגיאות ErrImagePull: ErrImagePull ContainerCreating    ניצול הדיסק נשאר קרוב ל-100% במהלך תהליך משיכת התמונה, בעיקר בשל הקלט/פלט הדיסק האינטנסיבי הנדרש לביטול הדחיסה (למשל, "unpigz"). ניצול דיסק גבוה:    חלק מה-DaemonSets של המערכת (כמו   או   ) עברו למצב "לא מוכן" עקב לחץ בדיסק, והשפיע על מוכנות הצומת. בעיות במערכת DaemonSet: aws-node ebs-csi-node    מכיוון שאנו משתמשים במופעי נקודתיים, איננו יכולים להשתמש בדיסק המקומי לאחסון תמונות במטמון. אין מטמון תמונה בצמתים:  זה גורם לפריסות עצומות רבות בענפי תכונה, במיוחד בגלל שב-FB השונה יש סטים שונים של תמונות בסיס.  לאחר חקירה מהירה, מצאנו שהבעיה העיקרית הייתה לחץ הדיסק על הצמתים על ידי תהליך   . תהליך זה אחראי לביטול הדחיסה של תמונות ה-docker. לא שינינו את הגדרות ברירת המחדל עבור סוג עוצמת הקול gp3 EBS, כי לא מתאים למקרה שלנו. unpigz  תיקון חם לשחזור האשכול  כצעד ראשון, החלטנו לצמצם את מספר ה-PODs על הצמתים.  אנו מעבירים את הצמתים החדשים למצב "קורדון".  הסר את כל ה-PODS התקועות כדי להפחית את לחץ הדיסק  הפעל אחד אחד את ה-PODs כדי לחמם את הצמתים  לאחר מכן, אנו מעבירים צמתים מחוממים למצב רגיל ("unCordon")  הסירו את כל הצמתים במצב תקוע  כל ה-PODS התחילו להשתמש בהצלחה במטמון התמונות של Docker   עיצוב CI/CD מקורי  הרעיון המרכזי של הפתרון הוא לחמם את הצמתים לפני שתהליך התקליטור מתחיל על ידי החלק הגדול ביותר של תמונת ה-docker (שכבת התלות של JS), המשמשת כתמונת השורש של כל האפליקציות שלנו. יש לנו לפחות 7 סוגים של תמונות השורש עם התלות ב-JS, שקשורים לסוג האפליקציה. אז בואו ננתח את עיצוב ה-CI/CD המקורי.     בצינור ה-CI/CD שלנו, יש לנו 3 עמודים:   צינור CI/CD מקורי:  בשלב   it: אנחנו מכינים את הסביבה/משתנים, מגדירים את סט התמונות לבנייה מחדש וכו'... Init  בשלב   : אנו בונים את התמונות ודוחפים אותן ל-ECR Build  בשלב   : אנו פורסים את התמונות ל-k8s (פריסות עדכון וכו'...) Deploy   פרטים נוספים על עיצוב ה-CICD המקורי:  הסניפים המאפיינים שלנו (FB) התפצלו מהסניף   . בתהליך ה-CI, אנו תמיד מנתחים את סט התמונות ששונו ב-FB ובונים אותם מחדש. הענף   תמיד יציב, כהגדרה, צריכה להיות תמיד הגרסה העדכנית ביותר של תמונות הבסיס. main main  אנו בנפרד בונים את ה-JS dependencies docker images (עבור כל סביבה) ודוחפים אותם ל-ECR כדי לעשות בו שימוש חוזר בתור תמונת השורש (בסיס) ב- Dockerfile. יש לנו בערך 5-10 סוגים של תמונת ה-JS dependencies docker.  ה-FB נפרס לאשכול k8s למרחב השמות הנפרד, אבל לצמתים המשותפים ל-FB. ה-FB יכול לכלול ~200 אפליקציות, עם גודל התמונה של עד 3 GB.  יש לנו את מערכת ה-Cluster Autoscaling, אשר מדרגת את הצמתים באשכול בהתבסס על העומס או ה-PODS הממתינים עם ה-nodeSelector והסבילות בהתאם.  אנו משתמשים במופעי הנקודה עבור הצמתים.  יישום תהליך החימום  יש דרישות לתהליך החימום.  הֶכְרֵחִי:    : מטפל ופותר בעיות   . פתרון בעיה ContainerCreating    : מפחית באופן משמעותי את זמן האתחול על ידי שימוש בתמונות בסיס מחוממות מראש (תלות ב-JS). ביצועים משופרים  נחמד שיש שיפורים:    : מאפשרת שינויים קלים בסוג הצומת ובתוחלת החיים שלו (למשל, SLA גבוה או זמן חיים ממושך). גמישות    : מספק מדדים ברורים על שימוש וביצועים. שקיפות    : חוסך בעלויות על ידי מחיקת ה-VNG מיד לאחר מחיקת ענף התכונה המשויך. יעילות עלות    : גישה זו מבטיחה שסביבות אחרות לא יושפעו. בידוד  פִּתָרוֹן  לאחר ניתוח הדרישות והאילוצים, החלטנו ליישם תהליך חימום שיחמם מראש את הצמתים עם תמונות המטמון הבסיסיות של JS. תהליך זה יופעל לפני תחילת תהליך התקליטור, מה שמבטיח שהצמתים מוכנים לפריסה של ה-FB, ויש לנו סיכוי מקסימלי להגיע למטמון.  את השיפור הזה חילקנו לשלבים גדולים בעץ:  צור את   (Virtual Node Group)  קבוצת הצמתים לכל FB  הוסף   עבור הצמתים החדשים תמונות בסיס לסקריפט של Cloud-init  הוסף   עם הקטע   כדי להוריד את תמונות ה-docker הדרושות לצמתים לפני תחילת תהליך התקליטור. שלב של פריסה מוקדמת להפעלת ה-DaemonSet initContainers     צינור CI/CD מעודכן ייראה כך:   צינור CI/CD מעודכן:    בשלב  1.1.(שלב חדש)   : אם זו התחלה ראשונה של ה-FB, אז צור סט אישי חדש של מופעי הצומת (במונחים שלנו זה Virtual Node Group או VNG) והורד את כל תמונות הבסיס של JS (5–10 תמונות ) מהסניף הראשי. זה מספיק הוגן לעשות את זה, כי חילקנו את ה-FB מהסניף הראשי. נקודה חשובה, לא מדובר בפעולת חסימה. התחל Init deploy  שלב  לבנות  שלב   הורד תמונות בסיס JS אפויות טריות עם תג FB הספציפי מה-ECR.  3.1.(שלב חדש)   : זוהי פעולת חסימה, כי עלינו להפחית את לחץ הדיסק. בזה אחר זה, אנו מורידים את תמונות הבסיס עבור כל צומת קשור.  אגב, תודה על שלב ה-   , כבר יש לנו את תמונות ה-docker הבסיסיות מהסניף הראשי, כלומר נותנים לנו הזדמנות גדולה להיכנס למטמון בהתחלה הראשונה. הפריסה מראש נקודות חשובות init deploy  **לִפְרוֹס  **אין שינויים בשלב זה. אבל הודות לשלב הקודם, כבר יש לנו את כל שכבות התמונה הכבדות של docker על הצמתים הדרושים.  התחל את שלב הפריסה    באמצעות קריאת API (למערכת קנה המידה האוטומטי של צד שלישי) מצינור ה-CI שלנו. צור קבוצה חדשה של צמתים עבור כל FB   בעיות שנפתרו:    : לכל FB יש קבוצה משלו של צמתים, מה שמבטיח שהסביבה לא מושפעת מ-FBs אחרים. בידוד    : אנו יכולים לשנות בקלות את סוג הצומת ואת תוחלת החיים שלו. גמישות    : אנו יכולים למחוק את הצמתים מיד לאחר מחיקת ה-FB. יעילות עלות    : אנו יכולים לעקוב בקלות אחר השימוש והביצועים של הצמתים (לכל צומת יש תג הקשור ל-FB). שקיפות    : מופע הנקודה מתחיל בתמונות בסיס מוגדרות מראש, כלומר, לאחר שהצומת הנקודתי מתחיל, יש כבר תמונות הבסיס על הצומת (מהענף הראשי). שימוש יעיל במופעי הנקודה    באמצעות סקריפט   . הורד את כל תמונות הבסיס של JS מהסניף הראשי לצמתים החדשים cloud-init  בזמן הורדת התמונות ברקע, תהליך התקליטור יכול להמשיך לבנות תמונות חדשות ללא בעיות. יתרה מכך, הצמתים הבאים (שייווצרו על ידי מערכת קנה מידה אוטומטי) מקבוצה זו ייווצרו עם הנתונים המעודכנים   , שכבר יש להם הוראות להורדת תמונות לפני ההתחלה. cloud-init  בעיות שנפתרו:    : לחץ הדיסק נעלם, מכיוון שעדכנו את הסקריפט של   על ידי הוספת ההורדה של תמונות הבסיס מהסניף הראשי. זה מאפשר לנו להיכנס למטמון בהתחלה הראשונה של ה-FB. פתרון הבעיה cloud-init    : מופע הנקודה מתחיל בנתונים מעודכנים   . זה אומר שאחרי שהצומת הנקודתי מתחיל, יש כבר תמונות הבסיס על הצומת (מהענף הראשי). שימוש יעיל במופעי הנקודה cloud-init    : תהליך התקליטור יכול להמשיך לבנות תמונות חדשות ללא בעיות. ביצועים משופרים  פעולה זו הוסיפה ~17 שניות (קריאת API) לצינור ה-CI/CD שלנו.  הפעולה הזו הגיונית רק בפעם הראשונה כשאנחנו מתחילים את ה-FB. בפעם הבאה, אנו פורסים את האפליקציות שלנו לצמתים קיימים שכבר יש להם את תמונות הבסיס, שסיפקנו בפריסה הקודמת.  שלב פריסה מראש  אנחנו צריכים את השלב הזה, כי תמונות FB שונות מתמונות הסניף הראשי. עלינו להוריד את תמונות הבסיס של FB לצמתים לפני תחילת תהליך התקליטור. זה יעזור להפחית את זמני ההתחלה הקרה הממושכים וניצול הדיסק הגבוה שיכול להתרחש כאשר מספר תמונות כבדות נמשכות בו זמנית.   המטרות של שלב הטרום-פריסה    : הורד ברצף את רוב התמונות הכבדות של Docker. לאחר שלב ה-init-deploy, כבר יש לנו את תמונות הבסיס על הצמתים, מה שאומר שיש לנו סיכוי גדול למטמון ההיט. מניעת לחץ בדיסק    : ודא שהצמתים מחוממים מראש עם תמונות דוקר חיוניות, מה שמוביל לזמני הפעלה מהירים יותר (כמעט מיידי) של POD. שפר את יעילות הפריסה    : צמצם למינימום את הסיכוי להיתקל בשגיאות   /   והבטח שקבוצות הדמונים של המערכת נשארות במצב "מוכן". שפר את היציבות ErrImagePull ContainerCreating  בשלב זה, אנו מוסיפים 10-15 דקות לתהליך התקליטור.  פרטי שלב טרום הפריסה:  בתקליטור אנו יוצרים DaemonSet עם הקטע   . initContainers  הקטע   מבוצע לפני שהמכל הראשי מתחיל, ומבטיח שהתמונות הדרושות יורדו לפני שהמכולה הראשית מתחילה. initContainers  בתקליטור אנו בודקים ללא הרף את המצב של daemonSet. אם daemonSet נמצא במצב "מוכן", אנו ממשיכים בפריסה. אחרת, אנחנו מחכים שה-demonSet יהיה מוכן.  השוואה  השוואה בין השלבים המקוריים והמעודכנים לתהליך החימום מראש.  שָׁלָב  התחל את שלב הפריסה  שלב פריסה מראש  לִפְרוֹס  זמן כולל  הבדל  ללא חימום מוקדם  0  0  11 מ' 21 שניות  11 מ' 21 שניות  0  עם חימום מוקדם  8 שניות  58 שניות  25 שניות  1 מ' 31 שניות  -9 מ' 50  העיקר, זמן "הפריסה" השתנה (מהפקודה הראשונה להחלה למצב ריצה של התרמילים) מ-11 מ' 21 שניות ל-25 שניות. הזמן הכולל השתנה מ-11 מ' 21 שניות ל-1 מ' 31 שניות. נקודה חשובה, אם אין תמונות בסיס מהסניף הראשי, אז זמן "הפריסה" יהיה זהה לזמן המקורי או קצת יותר. אבל בכל מקרה, פתרנו בעיה עם לחץ הדיסק וזמן ההתחלה הקרה.  מַסְקָנָה   הבעיה העיקרית   נפתרה בתהליך החימום. כהטבה, הפחתנו משמעותית את זמן ההתחלה הקרה של ה-POD.  לחץ הדיסק נעלם, כי כבר יש לנו את תמונות הבסיס על הצמתים. מערכת daemonSets נמצאים במצב "מוכן" ו"בריא" (מכיוון שאין לחץ בדיסק), ולא נתקלנו בשגיאות   הקשורות לבעיה זו. ContainerCreating ErrImagePull  פתרונות אפשריים וקישורים  השתמש במופעים   עבור הצמתים במקום   אנחנו לא יכולים להשתמש בדרך זו, כי היא מחוץ לתחום התקציב שלנו עבור סביבות שאינן ייצור. לפי דרישה מופעי הנקודה    אנחנו לא יכולים להשתמש בדרך זו, כי תכונה זו גם מחוץ להיקף התקציב שלנו עבור סביבות שאינן ייצור. יתר על כן, ל-AWS יש את   של IOPS עבור חשבונך לפי אזור. השתמש בסוג עוצמת הקול של Amazon EBS gp3 (או טוב יותר) עם ה-IOPS המוגבר המגבלות    למעשה אנחנו לא יכולים לזוז בדרך הזו, כי זה משפיע יותר מדי על הייצור ועל סביבות אחרות, אבל זה גם פתרון טוב לבעיה שלנו. צמצם את זמן ההפעלה של מיכל ב- Amazon EKS עם נפח הנתונים של Bottlerocket   פתרון בעיות של Kubernetes Cluster Autoscaler לוקח שעה אחת כדי להגדיל 600 תרמילים    ברצוני להודות לצוות הטכני הנהדר ב-   (   ) על העבודה הבלתי נלאית והגישה היצירתית באמת לכל נושא שהם מתמודדים איתם. עִם. במיוחד, צעקה לרוני שרעבי, המוביל המעולה שאחראי על העבודה הנהדרת שהצוות עושה. אני מצפה לראות עוד ועוד דוגמאות נהדרות לאופן שבו היצירתיות שלך משפיעה על המוצר Justt. נ.ב.: Just https://www.linkedin.com/company/justt-ai

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

האודיו הזה מופק בשפת המקור של הסיפור!

יותר מדי זמן; לקרוא

Make resilience your competitive advantage

כיצד לייעל את Kubernetes עבור תמונות Docker גדולות

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

The TechBeat: 5 Low-Cost Cybersecurity Measures SMBs Can’t Afford to Not Implement (3/4/2024)

The TechBeat: Everything You Need to Know to Implement Generative AI for Your Enterprise (3/12/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/22/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/10/2024)

The TechBeat: 5 Low-Cost Cybersecurity Measures SMBs Can’t Afford to Not Implement (3/4/2024)

The TechBeat: Everything You Need to Know to Implement Generative AI for Your Enterprise (3/12/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/22/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/10/2024)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps