Azure Kubernetes Service מוכן לייצור: הגדרת AKS עם Terraform

אשכול Azure AKS: מה נשבר כשהעומס גדל

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

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

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

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

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

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

מהירות פריסת גרסה חדשה של השירות

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

שחזור מנוהל לאחר כשל צומת

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

מחלקת תקלות שסולקה בגלל עריכות ידניות

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

אפשרויות פריסה של Azure AKS: מה ומתי מתאים

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

לאילו משימות נדרשת תצורה ידנית

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

היכן מוצדק תיאור מלא של התשתית כקוד

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

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

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

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

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

מערך המסירה: קונפיגורציות, סכימות ונהלים

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

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

מקרה בוחן: אשכול לעומס שיא של חנות מקוונת

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

מה בדיוק שינו

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

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

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

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

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

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

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

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

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

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

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

ספקות טכניים: רשת, הרשאות ועדכונים

רשת, הרשאות וסדר עדכונים — מה שהכי часто עולה לפני העברת האשכול לסביבת העבודה. להלן תשובות לשאלות שנשאלות לפני ההתחלה, כדי שגבולות העבודה יהיו ברורים מראש.

כיצד מבודדות הסביבות — בדיקות, קדם-ייצור וייצור?

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

מה נכלל בגיבוי?

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

היכן גבול האחריות בין הצוות שלכם לצוות שלנו?

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

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

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

בשיחה הראשונה נברר:

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

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

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