תצורות Kustomize מקצה לקצה: overlay + GitOps ל-Kubernetes

פיתוח תצורות Kustomize: היכן ניהול ידני נשבר

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

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

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

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

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

האפקט בתפעול: מהירות פרסום, חזרה ושחזור

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

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

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

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

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

מודלי עבודה עם תצורות: השוואת גישות

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

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

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

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

שלבי הטמעה: מביקורת ועד מסירת נהלים

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

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

הרכב האספקה: מאגר, סכמות סביבות, נהלים והרשאות

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

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

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

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

מה היה לפני

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

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

מה נהיה אחרי

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

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

במה שונה בנייה דקלרטיבית מתבניות?

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

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

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

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

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

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

אצלנו הכול מוגדר ביד — לכתוב מאפס?

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

אפשר לבצע מיגרציה בלי לעצור את הפרודקשן?

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

למה הסטנד והפרודקשן מתפצלים?

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

מה קורה אחרי המסירה?

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

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

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

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

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

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