הקמת אשכול Kubernetes מאפס (kubeadm): זמינות גבוהה בפרודקשן

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

הגדרת kubeadm לפי מדריך מהיר נראית כמעט זהה בכל מקרה: kubeadm init על מכונה אחת, צמתי העבודה מתחברים דרך kubeadm join, ו-kubectl get nodes מציג רשימה ירוקה ואחידה. הפודים נפרסים, השירותים מגיבים, והאשכול נראה עמיד בפני כשלים. אבל כל מעגל הניהול מורכב בעותק בודד, ושולי העמידות של תצורה כזו הם אפס.

צומת ניהול בודד מחזיק בבת אחת את kube-apiserver, kube-scheduler, kube-controller-manager ו-etcd — הכול בעותק אחד.

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

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

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

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

מה נותן אשכול עמיד בפני כשלים: השבתה וזמן השחזור

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

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

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

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

איזה סוג כשל נעלם

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

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

טופולוגיות של צומתי ניהול: השוואת אפשרויות פריסה

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

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

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

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

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

הגדרת kubeadm: שלבי העבודה מהביקורת ועד המסירה

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

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

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

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

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

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

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

תיעוד, תרשימים ותקנונים בפלט הפרויקט

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

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

• קבצי תצורה: kubeadm-config, מניפסטים של שכבת הניהול, פרמטרים של kubelet ושל סביבת הרצת הקונטיינרים, צ'ארטים עבור Ingress, DNS וניטור — הסביבה נפרסת בסביבה נקייה באופן ניתן לשחזור.
• תרשים רשת וכתובות: טווחי רשת הפודים והשירותים, איזון בקשות ל-API, חיבורים לרשתות חיצוניות וניתוב בין אזורים.
• תרשים עמידות בפני כשלים: מספר צמתי שכבת הניהול, הקוורום של etcd, מיקום גיבויי המצב, התנהגות האשכול בעת אובדן אזור.
• מדיניות גישה: תפקידים וקשירות RBAC, חשבונות שירות, בידוד מרחבי שמות, מדיניות רשת וכללי קבלה של עומסי עבודה.
• תקנון עדכון: סדר עדכון הצמתים, בדיקות לפני הוצאה מפעילות, קריטריונים לחזרה אחורה ועומק שמירת גרסאות התמונות הקודמות.
• תקנון שחזור ותיעוד האשכול: תרחישי אובדן צומת ומאגר מצב, זמן השחזור היעד, מפת האשכול, הגדרות התראות ויומן מגבלות ידועות.

מקרה בוחן: שלושה צומתי ניהול, כשל של אחד בלי השבתה

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

כשל של אותו צומת עצר את ה-API — לא ניתן היה להוציא גרסה או לבדוק את מצב הפודים, והשחזור מצילום ארך 40–50 דקות: להקים את הצומת, להחזיר תעודות, להשוות כתובות, ולחכות ש-kubelet יראה שוב את מכונות העבודה.

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

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

מדדים לפני ואחרי

• כשל של צומת ניהול: לפני — עד 50 דקות של שחזור ידני ואי-זמינות מלאה של ה-API; אחרי — העברה לצומת חלופי בפחות מדקה, השירותים ממשיכים להגיב.
• פעולות ידניות בעת תקלה: לפני — 12–15 צעדים לפי רשימת בדיקה; אחרי — אפס: הקוורום והכתובת הווירטואלית משתחזרים מעצמם.
• עדכונים מתוכננים בלי עצירת שירותים: לפני — כחצי, והשאר בחלון השבתה; אחרי — 100%, פינוי הפודים נכנס למצב עומס רגיל.
• הוספת צומת חדש למעגל: מכמה שעות לעשרות דקות לפי תרחיש אחד ניתן לשחזור.

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

מה לעשות אם האשכול כבר הורכב ידנית?

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

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

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

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

שאלות טכניות נפוצות: רשת, עדכונים, כשל צמתים

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

באיזה סדר לעדכן את האשכול?

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

מה יקרה בעת כשל של צומת או פיצול רשת?

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

כיצד מאורגן הגיבוי של המצב?

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

נדון במשימה שלכם: נבנה תוכנית והערכת עבודות

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

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

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