מדוע התקנת CRI-O נשברת בשלב החיבור לרשת
התקנת ה-runtime עצמה עוברת בצורה נקייה — מה שנשבר הוא החיבור. ה-node לא מגיע למוכנות: kubelet פונה ל-socket של ה-runtime של הקונטיינרים, זה מעלה את ה-pod sandbox, אך רכיב הרשת של הקלאסטר לא מוצא את הקונפיג שלו בספרייה הצפויה או קורא אותו מגרסה אחרת — וה-sandbox נשאר בלי כתובת.
ה-pods תלויים בהמתנה, באירועים נופלות שגיאות קונפיגורציה של ה-runtime, ואחריהן נופל ה-DNS הפנימי וכל מה שתלוי בו.
הסיבה השנייה — אי-סנכרון של נתיבים והגדרות. ה-runtime ותוסף ה-CNI מתעדכנים בנפרד, ואחרי תיקון נוסף הספרייה עם הקונפיגורציה זזה: ה-runtime מחפש קבצים במקום אחד, והתוסף — במקום אחר.
בסביבת הבדיקה הכול מסתדר, אבל על node הייצור הפער צף אחרי יממה, ולכן מחפשים את הסיבה זמן רב ובאופן עיוור.
וההרגל היקר ביותר — תיקונים ידניים ישירות על nodes פעילים. הקונפיגורציה של ה-runtime ורכיב הרשת מתוקנת על node פעיל כדי להחזיר אותו מהר לפעולה; ה-node הבא נפרס מתבנית ומשחזר את אותה שגיאה. ה-nodes מתפצלים ביניהם, הקלאסטר מפסיק להיות משוחזר, והחזרה לאחור צריכה להיעשות ידנית תחת עומס.
לא ההתקנה נשברת, אלא החיבור בין ה-runtime לרשת. אנחנו מפרקים כיצד זה נסגר: מקור קונפיגורציה אחיד במקום תיקונים על ה-nodes, בדיקת החיבור לפני הייצור וסדר החלה שבו ה-node או עולה כולו, או לא עולה כלל.
מה משתנה בעבודת הקלאסטר לאחר הגדרת ה-runtime
המעבר ל-CRI-O משנה לא רק את פקודת ההפעלה, אלא גם את נקודת החיבור עצמה בין kubelet לסביבת הקונטיינרים. CRI-O מממש את ממשק הקונטיינרים ישירות, ללא daemon מתווך: תהליך אחד על ה-node, מינימום צעדים בין בקשת kubelet ליצירת ה-pod sandbox.
בפועל זה מקצר את זמן הכנסת ה-node לעבודה — ה-node מגיע למצב מוכנות תוך שניות לאחר הפעלת השירות, ולא לאחר התחממות של כמה daemons וסנכרון המצבים שלהם.
אפקט נפרד — נעלם סוג שלם של כשלים בנקודת החיבור בין ה-runtime לרשת. תוסף ה-CNI מתחבר ל-runtime כמקור קונפיגורציה יחיד, וסדר האתחול של הרשת וה-sandbox מוקבע בקבצי הקונפיגורציה, ולכן לאחר הפעלה מחדש של ה-node לא נשארים pods שלכאורה עלו אך נותרו בלי כתובת או נתיב. בעבר פערים כאלה היו מאתרים ידנית לפי הלוגים — כעת אין היכן לשחזר אותם.
זמן השחזור של הקלאסטר לאחר תקלה נחשב אחרת. מצב ה-sandboxes נשמר על הדיסק, ובהפעלה ה-runtime מעלה אותם בסדר המקורי, בלי ליצור מחדש את הקונטיינרים במלואם: עומסי העבודה חוזרים ברצף קפדני — תחילה המערכתיים, אחר כך האפליקציות. הפעלה מחדש שגרתית של node מסתיימת תוך עשרות שניות, וחירום מתנהל לפי תרחיש צפוי ללא התערבות ידנית.
פרופיל העומס על ה-nodes נעשה אחיד יותר: תהליך runtime אחד מחזיק נפח זיכרון קבוע, נעלמים פיקים מעיבוד מחדש של אינדקס התמונות, וצפיפות פריסת עומסי העבודה גדלה בלי החלפת חומרה.
היציבות באה לידי ביטוי בסטטיסטיקה היומית של הפעלות מחדש של קונטיינרים — מספרן יורד למקרים בודדים, ולכל אחד כבר יש סיבה מובנת.
מצבי פריסה של ה-runtime: השוואת אפשרויות
התקנת CRI-O היא רק חלק מהפתרון: מצב הפריסה קובע מי אחראי לעדכוני ה-runtime ומה בכלל ניתן לשנות על ה-node. להלן ארבע חלופות ממשיות: שתי דרכים להשיג את ה-runtime ושתי דרכים למקם אותו.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חבילות ממאגר ההפצה | קונטור סטנדרטי, עדכונים יחד עם מערכת ההפעלה | זמינה רק הגרסה מענף ההפצה, תיקונים מגיעים באיחור |
| בנייה מקוד המקור | נדרש סט מודולים משלך, יכולות מיותרות מושבתות | תאימות ל-kernel והעדכונים מוטלים על הצוות |
| runtime על כל node | קונטור עצמאי, שליטה מלאה בפרמטרים | יש לעדכן ולסנכרן את ה-nodes בתיאום: גרסאות שנתפצלו שוברות את תזמון העומסים |
| קלאסטר מנוהל של ספק | נדרשת תוצאה, לא ליווי שכבת הניהול | גרסת ה-runtime וחלק מהקונפיגורציה נקבעים על ידי הספק, לא ניתן לחבר מודולי kernel משלך |
בנפרד יש לציין את מגבלת הבידוד ללא הרשאות root: ה-runtime עולה ממשתמש לא מיוחס, לא כותב מחדש את חוקי הרשת של ה-node ולא רואה חלק מההתקנים. עומסים מיוחסים וחלק מתוספי הרשת לא עולים במצב כזה — אם הקונטור דורש גישה להתקני בלוק, יהיה צורך לשקול מחדש את המצב.
המצב נקבע לפני הפריסה: שינוי שיטת ההתקנה על קונטור פעיל משמעו התקנה מחדש של ה-runtime והפעלה מחדש של כל העומסים על ה-node. לכן האפשרות נבחרת בהתאם לתשובה לשאלה מי מתחזק את הקונטור — צוות פנימי או ספק.
התקנת CRI-O: שלבי העבודה מביקורת ה-nodes ועד המסירה
התקנת CRI-O על קלאסטר חי היא לא פקודה אחת, אלא רצף שבו טעות באמצע עוצרת את עומסי העבודה. ה-runtime קשור ל-kubelet, לתוסף הרשת ולהגדרות בידוד התהליכים, ולכן תחילה מתעדים את המצב הנוכחי, ואחר כך משנים node אחר node תוך שמירה על אפשרות חזרה לאחור. להלן סדר העבודות שאנו חוזרים עליו בכל קלאסטר.
- ביקורת של nodes הקלאסטר. אוספים גרסאות של ה-kernel והחבילות, דרייברים של האחסון, הגדרות kubelet, תוספי רשת פעילים ורשימת תמונות עם סכומי בדיקה. התוצאה — דוח עם צווארי בקבוק: היכן CRI-O יעלה בלי בנייה מחדש של ה-node, והיכן נדרש שדרוג מקדים.
- סכימת קונפיגורציה של ה-runtime. מתכננים מדיניות משיכת תמונות, מגבלות על תהליכים ו-file descriptors, הוצאת האחסון ל-volume נפרד, פרמטרים של תיעוד ורוטציה של לוגים.
- התקנה על node פיילוט. מתקינים מהמאגר הרשמי, משווים את כתובת ה-socket של ה-runtime להגדרות kubelet, מריצים בדיקות של הפעלה ועצירה של קונטיינר.
- קונטור בדיקה של הקלאסטר. פורסים עותק של פרופיל הייצור ועוברים תרחישים: פריסה, הפעלה מחדש של pod, עדכון תמונה, בידוד רשת, התנהגות בעת כשל של node.
- העברת nodes הייצור אחד-אחד. ה-node מוצא מאיזון העומסים, ה-runtime מוחלף, ה-node חוזר לרוטציה — עם הפסקה למדדים כדי שהמצב הקודם יישאר ניתן לשחזור.
- מסירת נהלי התפעול. מוסרים את הסכימה, הוראות עדכון, צ'ק-ליסט אבחון ומפת חזרות לאחור, ועוברים עליהם עם המשמרת התורנית.
ערכת המסירה: קונפיגורציות, סכימות רשת ונהלים
ערכת המסירה נאספת כך שמהנדס תורן יוכל להעלות את ה-runtime מאפס על node חדש ולשחזר אותו לאחר תקלה בלי התכתבות איתנו. כל קובץ מנוהל בגרסאות יחד עם קונפיגורציית הקלאסטר ומצויד בהערה: מהו הפרמטר, מדוע נבחר כך ומה ישתנה אם יתוקן.
- קבצי קונפיגורציה של ה-runtime: קונפיג בסיסי, מגבלות על מספר ה-pods וה-file descriptors הפתוחים, פרמטרים של תיעוד ומדיניות הפעלה מחדש — עם הסבר לכל ערך לא מובן מאליו.
- סכימת מיעון של pods ושירותים: מאגר כתובות, גודל תת-רשת לכל node, טווחים של רשתות שירות וחישוב לכמה nodes תספיק הסכימה עד להרחבה.
- מדיניות גישה ל-nodes: תפקידים וקשרים, הגבלות כניסה, הפרדת הרשאות בין התורן למנהל, סדר העבודה עם מפתחות ותעודות.
- נוהל עדכון ה-runtime: הוצאת ה-node משירות, בדיקת תאימות התמונות, חלון חזרה לאחור וקריטריונים שבהם עוצרים את העדכון.
- קונפיגורציית הרשת ותוסף הרשת המחובר: מניפסטים, מצב הניתוב הנבחר, בדיקות קישוריות בין pods על nodes שונים ועם שירותים חיצוניים.
- הוראות אבחון: כשלים אופייניים, סט פקודות ללקיחת מצב, ספים שאחריהם האירוע עולה לדרג גבוה יותר.
- מפת רכיבים וצ'ק-ליסט קבלה: מה רץ היכן, במה הוא תלוי ואילו שינויים דורשים תיאום.
מקרה בוחן: הקלאסטר יצא מכשלים לאחר הגדרת הרשת
מה היה
הקלאסטר חי במצב מעורב: חלק מה-nodes עבדו על סביבת הרצה ישנה, חלק — על חדשה, ושכבת הרשת הוגדרה בנפרד ובידני. הקונטיינרים עלו אך לא קיבלו כתובת — החל מעגל של הפעלות מחדש, ועד 7% מההפעלות בשעות שיא הסתיימו בכשל. התורן כמעט בכל משמרת תיקן קונפיגורציות על nodes מסוימים, והשחזור לאחר תקלה כזו נמשך עד 40 דקות.
מה עשינו
העברנו את הקלאסטר ל-CRI-O כסביבת ההרצה היחידה וקבענו את סדר האתחול: תחילה עולה מודול הרשת, ואחר כך סביבת ההרצה לוקחת הגדרת רשת מוכנה. קונפיגורציות ה-nodes הפסיקו להיות «חיות» — הן נמצאות במערכת בקרת גרסאות, נפרסות בפקודה אחת ונבדקות לפני ההחלה.
מדיניות הבידוד ופרמטרי הרשת מתוארים באופן דקלרטיבי, ולכן אין עוד צורך בתיקונים ידניים על ה-nodes: כל סטייה מהתקן נראית מיד.
מה נהיה
שיעור ההפעלות המוצלחות — 99.9%, כשלים בנקודת החיבור בין סביבת ההרצה לרשת בתקופה הנצפית אין. זמן השחזור הצטמצם מ-40 ל-4-6 דקות, וההתערבויות הידניות — מכ-20 בחודש לאחת-שתיים מתוכננות.
הקלאסטר הפסיק לדרוש נוכחות קבועה של מהנדס תורן בלילה, והעברת nodes נוספים לאותו runtime דרשה נוהל אחד במקום פרויקט נפרד.
מה עושים אם על ה-nodes כבר פרוס runtime אחר?
ה-runtime עבור ה-node הוא פרט מימוש: האורקסטרטור מתקשר איתו דרך ממשק תקני, ולכן מניפסטים, שירותים ומדיניות רשת בעת המעבר ל-CRI-O אינם נכתבים מחדש.
לפני המיתוג הראשון יש לבדוק שלושה דברים: התאמה של דרייבר ה-cgroup להגדרות kubelet, תאימות תוסף הרשת הנבחר ועבודה עם מאגר פרטי — אחרת ה-pods ייתקעו בהמתנה לתמונה או יישארו בלי רשת.
המיתוג נעשה node אחר node וללא עצירת עומסים. תחילה ה-node מסומן כבלתי זמין לתזמון, ואחר כך ה-pods מפונים ממנו — ה-nodes השכנים קולטים אותם. לשם כך נדרש מלאי משאבים במאגר, ומדיניות ההפרעות מוגדרת כך שהפינוי לא יקצץ את הקוורום של השירות. כל עוד ה-node ריק, ה-runtime הישן נעצר, מותקן ומוגדר CRI-O, ו-kubelet עובר ל-socket החדש.
ה-node מוחזר לפעולה רק לאחר בדיקה: pod עולה, exec עובד, לוגים נקראים, volumes מותקנים. ראשון עובר node אחד במאגר הבדיקות — עליו מריצים תרחישים עם תמונות פרטיות וחיבור אחסון, וה-node חוזר למאגר הכללי כשההתנהגות תואמת את המצופה.
את החזרה לאחור מחזיקים מוכנה: ה-runtime הישן נשאר מותקן, kubelet חוזר ל-socket הקודם, וה-node שוב מוצא מהעבודה. סדר הוצאת ה-nodes אינו משתנה: אחד-אחד, עם הפסקה לבדיקה, בלי מיתוג בו-זמני של כל המאגר.
ספקות טכניים: שאלות נפוצות על ה-runtime של הקונטיינרים
לפני קבלת הקלאסטר הלקוח בודק לא «האם ה-runtime עלה», אלא את התנהגות החיבור כולו: אורקסטרטור, runtime, תוסף רשת, אחסון תמונות. רוב האירועים לאחר ההפעלה הם לא כשלים של ה-runtime עצמו, אלא אי-התאמה של גרסאות ופרמטרים בין הרכיבים, שאינה מתגלה בסביבת בדיקה של שלושה nodes.
להלן השאלות שנשמעות לרוב בשלב המסירה. חלק מהתשובות תלויות בטופולוגיה שלכם, ולכן אנו בודקים את הקונפיגורציה על הקלאסטר שלכם, ולא על סכימה טיפוסית.
האם ה-runtime תואם לגרסת האורקסטרטור שלנו?
CRI-O מממש ממשק תקני ומתעדכן יחד עם האורקסטרטור לפי מטריצת תאימות רשמית. אנו מקבעים זוגות גרסאות מותרים בקונפיגורציה ובסכימת העדכון — אז שדרוג של רכיב אחד לא שובר את האחר.
האם את תוסף הרשת מגדירים אתם, או שהוא נשאר באחריותנו?
הרשת חיה בנפרד מה-runtime: ה-runtime רק קורא לתוסף בעת יצירת הקונטיינר. אנו מאחדים את קונפיגורציית הרשת על כל ה-nodes, בודקים את סדר הטעינה, היעדר התנגשויות עם רכיבי המערכת ופירוש נכון של כתובות בעת הפעלה מחדש של pod.
מה קורה בעת עדכון ה-runtime על קלאסטר חי?
מעדכנים node אחר node עם פינוי עומסי עבודה, כדי שהאפליקציות יעברו ל-nodes שכנים בלי השבתה. בנפרד מתכננים קונטיינרים עם volumes מקומיים והצמדה ל-node. חזרה לאחור — לגרסה יציבה קודמת, עד שה-node יחזור לפעולה.
מה נשאר לאחר המסירה — קלאסטר עובד או תיעוד?
ערכה: מניפסטים של ה-runtime והרשת תחת בקרת גרסאות, סכימת עדכון וחזרה לאחור, סט בדיקות למצב ה-nodes, נוהל לפעולות אופייניות. המהנדסים שלכם משחזרים את הסביבה מאפס לפי החומרים האלה.
כיצד לוודא שקונפיגורציית הקלאסטר תקינה?
מריצים צ'ק-ליסט קבלה: משווים פרמטרים של ה-runtime והרשת על כל node, בודקים הפעלה מחדש של node, שחזור לאחר נפילת עומס, והתנהגות בעת אי-זמינות של מאגר התמונות. בסיום — דוח עם פערים לפני ואחרי התיקונים.
נדון במשימה: תוכנית עבודה והרכב המסירה
כדי שהשיחה תהיה ענייני, תארו את הקונטור: כמה nodes יש בקלאסטר ומה תפקידו של כל אחד, איזה מנוע קונטיינרים פועל כעת, היכן נשמרות התמונות והאם נדרשות מדיניות רשת בין מרחבי שמות. אם יש סכימת רשת, קונפיגורציות עובדות ויומן של התקלות האחרונות — צרפו, זה מסיר חצי מהשאלות עוד לפני השיחה.
- גרסת המערכת וה-kernel על ה-nodes, מודולים זמינים ודרייברים של אחסון;
- תרחיש הפריסה: תחילה סביבה נפרדת או מיד קונטור פעיל;
- מי הבעלים של הקטע הרשתי ובאיזה סדר מתואמים הכללים;
- חלון השינויים וזמן האי-זמינות המותר של השירותים;
- דרישות לעדכון תמונות ולחזרה לגרסה קודמת;
- מי מהצוות שלכם מקבל את העבודה ולפי אילו קריטריונים.
עם זה נחזור עם חבילה שעל פיה אפשר לקבל החלטה:
- תוכנית שלבי ההטמעה עם נקודות בדיקה אחרי כל צעד;
- סכימת מיקום הרכיבים, אזורי הרשת ואחסון התמונות;
- הערכת העבודות לקלאסטר: הרכב ה-nodes, ההיקף והרצף;
- הרכב המסירה: קונפיגורציות, מדיניות אבטחה, נוהל תחזוקה, הוראות למשמרת התורנית;
- סדר תיאום השינויים ומטריצת האחריות.
תארו את המשימה בצורה חופשית — נחזור עם תוכנית והערכה.