EKS לפרודקשן: הגדרת ALB, EBS, סודות וניטור

AWS EKS production: היכן הקלאסטר נשבר

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

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

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

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

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

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

מה נותנת הגדרת קונטור פרודקשן

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

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

זמן התאוששות ועמידות בתקלות

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

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

עדכון ללא השבתה

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

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

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

מצבי עבודה ואפשרויות הרכבה של הקלאסטר

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

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

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

שלבי ההטמעה: מהאודיט ועד למסירה

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

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

קונפיגורציות, סכמות ותקנונים בפלט

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

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

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

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

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

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

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

מטריקות לפני ואחרי

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

במה נבדל קלאסטר מנוהל מהרכבה ידנית?

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

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

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

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

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

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

שאלות נפוצות על הגדרת הקלאסטר

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

כיצד לעדכן צמתים ללא השבתה?

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

האם הקלאסטר משתלב בקונטור קיים?

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

מה היקף העבודה וממה נתחיל?

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

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

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

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

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