חמש החמצות בעת פריסת האפליקציה הראשונה ב-Kubernetes

כישלון מאת אריס-דרימר

אנשים רבים מאמינים שמספיק להעביר את האפליקציה ל-Kubernetes (באמצעות Helm או ידנית) והם ישמחו. אבל זה לא כל כך פשוט.

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

שלב ראשון: הגדרת בקשות ומגבלות של פוד

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

בקשות פוד - זהו הערך העיקרי המשמש את המתזמן כדי למקם את התרמיל בצורה מיטבית.

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

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

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

מגבלות תרמילים - זהו גבול ברור יותר לתרמיל. הוא מייצג את כמות המשאבים המקסימלית שהאשכול יקצה למיכל.

שוב, מ תיעוד רשמי: אם למיכל יש מגבלת זיכרון של 4 GiB, אזי ה-kubelet (וזמן הריצה של המיכל) יאכפו אותה. זמן הריצה אינו מאפשר למכולה להשתמש יותר ממגבלת המשאבים שצוינה. לדוגמה, כאשר תהליך בקונטיינר מנסה להשתמש ביותר מכמות הזיכרון המותרת, ליבת המערכת מפסיקה את התהליך עם שגיאת "חסר זיכרון" (OOM).

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

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

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

1. באמצעות כלי בדיקת עומס, אנו מדמים רמת תעבורה בסיסית ומנטרים את השימוש במשאבי הפוד (זיכרון ומעבד).
2. אנחנו מגדירים את בקשות הפוד לערך נמוך באופן שרירותי (עם הגבלת משאבים של בערך פי 5 מערך הבקשות) ומתבוננים. כאשר הבקשות נמוכות מדי, התהליך לא יכול להתחיל, ולעתים קרובות גורם לשגיאות זמן ריצה מסתוריות של Go.

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

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

שלב שני: הגדרת מבחני חיוניות ומוכנות

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

חי מראה אם ​​המכולה פועלת. אם הוא נכשל, ה-kubelet הורג את המיכל ומדיניות הפעלה מחדש מופעלת עבורו. אם המכולה לא מצוידת ב- Liveness, אז מצב ברירת המחדל יהיה הצלחה - זה מה שהוא אומר בו תיעוד Kubernetes.

בדיקות Liveness צריכות להיות זולות, כלומר הן לא אמורות לצרוך משאבים רבים, מכיוון שהן פועלות לעתים קרובות וצריכות ליידע את Kubernetes שהאפליקציה פועלת.

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

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

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

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

בדיקות מוכנות צורכות יותר משאבים מכיוון שהם חייבים להישלח ל-backend באופן שמציין שהאפליקציה מוכנה לקבל בקשות.

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

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

SELECT small_item FROM table LIMIT 1

הנה דוגמה לאופן שבו אנו מגדירים את שני הערכים הללו ב-Kubernetes:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

אתה יכול להוסיף כמה אפשרויות תצורה נוספות:

• initialDelaySeconds - כמה שניות יעברו בין השקת המכולה לתחילת הפעלת הדגימות.
• periodSeconds - מרווח המתנה בין ריצות מדגם.
• timeoutSeconds - מספר השניות שאחריהם היחידה נחשבת למצב חירום. פסק זמן קבוע.
• failureThreshold - מספר כשלי הבדיקה לפני שליחת אות הפעלה מחדש לתרמיל.
• successThreshold - מספר הבדיקות המוצלחות לפני שהפוד נכנס למצב מוכן (לאחר כשל, כאשר הפוד מתחיל או מתאושש).

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

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

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

לדוגמה, להלן מדיניות פשוטה שמונעת כל תעבורה נכנסת עבור מרחב שמות ספציפי:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

הדמיה של תצורה זו:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
פרטים נוספים כאן.

שלב רביעי: התנהגות מותאמת אישית באמצעות ווים ומיכלי init

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

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

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

והנה nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

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

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

שלב חמישי: הגדרת הליבה

לבסוף, בואו נדבר על טכניקה מתקדמת יותר.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

לסיכום

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

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

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

שאל את עצמך תמיד את השאלות האלה:

1. כמה משאבים צורכות יישומים וכיצד ישתנה נפח זה?
2. מהן דרישות קנה המידה האמיתיות? כמה תעבורה האפליקציה תטפל בממוצע? מה לגבי עומסי שיא?
3. באיזו תדירות השירות יצטרך להתאים לרוחב? באיזו מהירות צריך להביא פודים חדשים לאינטרנט כדי לקבל תנועה?
4. באיזו מידה נסגרות התרמילים? האם זה נחוץ בכלל? האם ניתן להשיג פריסה ללא זמן השבתה?
5. כיצד ניתן למזער סיכוני אבטחה ולהגביל את הנזק מכל תרמיל שנפגע? האם לשירותים כלשהם יש הרשאות או גישה שהם לא דורשים?

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

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

מה עוד לקרוא:

1. שיטות עבודה מומלצות ושיטות עבודה מומלצות להפעלת קונטיינרים ו-Kubernetes בסביבות ייצור.
2. 90+ כלים שימושיים עבור Kubernetes: פריסה, ניהול, ניטור, אבטחה ועוד.
3. הערוץ שלנו Around Kubernetes בטלגרם.

מקור: www.habr.com