הגדרת AWS EKS: אשכול מוכן לפרודקשן

הגדרת EKS ב-AWS: היכן הקלאסטר מאבד יציבות

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

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

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

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

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

אפקט מדיד: יציבות ומהירות התאוששות

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

יציבות והתאוששות

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

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

סקיילינג ועדכונים

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

מה בודקים בקבלה:

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

גישות לפריסה: AWS מנוהל או הרכבה ידנית

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

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

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

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

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

ארטיפקטים הנמסרים: קונפיגורציות, סכמות, תקנונים

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

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

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

התמונה ההתחלתית

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

בשיאים זה הניב דעיכה צפויה — זמן התגובה עלה מ-400 מ"ש ל-3 שניות, שיעור הבקשות עם שגיאות הגיע ל-4–5%, ועותקים חדשים של השירותים הופיעו 8–12 דקות לאחר תחילת גידול התעבורה.

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

מה שינו

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

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

כיצד מדדו את התוצאה

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

במהלך רבעון שיעור הכשלים בשיא ירד מ-4–5% ל-0.2%, זמן התגובה — מ-3 שניות ל-700 מ"ש, הוספת עותקים הואצה מ-12 דקות ל-90 שניות, והתאוששות השירות ארכה 4 דקות במקום 35. מספר האירועים שדרשו התערבות ידנית הצטמצם מתשעה לאחד.

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

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

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

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

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

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

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

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

מה יקרה בעת כשל של אזור זמינות?

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

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

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

כיצד לשלוט בצריכת המשאבים?

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

כיצד להעביר שירותים קיימים?

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

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

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

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

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

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