האשכול סוטה מ-Git: היכן נשבר ה-auto-sync kubernetes
סנכרון האשכול עם Git נכשל לעיתים רחוקות לחלוטין — בדרך כלל הוא מופעל, אך עם חריגים. מישהו תיקן את המגבלות של pod דרך kubectl «לחמש דקות», מישהו הוסיף annotation ביד בזמן שטיפל בתקלה.
כל עוד ה-auto-sync kubernetes מוגדר לפי העיקרון «החל ושכח», תיקונים כאלה חיים בשלווה באשכול עד הריליס הבא ואינם נכנסים לאף קומיט.
לאחר כמה שבועות חוסר הסנכרון של האשכול מפסיק להיות אוסף של זוטות. תיקונים ידניים באשכול מצטברים, Git מתאר סביבה אחת ובפועל פועלת אחרת, וההבדל אינו מתועד בשום מקום.
דריפט של קונפיגורציות מכה בתרחיש הגרוע ביותר: הסביבה נבנית מחדש מאפס מהריפו, והאפליקציה עולה לא כפי שהיא בסביבת הפרודקשן — כי חלק ממצב העבודה חי רק באשכול החי.
זה נשבר במקומות צפויים. החלה מחדש אוטומטית (self-heal) כבויה, ולכן הפער פשוט מצטבר. מחיקת אובייקטים שנעלמו מהריפו לא מופעלת — משאבי זבל נשארים באשכול. רשימת החריגים להשוואת מצבים תפחה עד כדי כך שהכלי מפסיק להבחין בשינויים אמיתיים. בנוסף, למהנדסים נשארת גישה ישירה לכתיבה, כלומר עקיפת Git שוב אפשרית בכל רגע.
יכולת השחזור של סביבות נשענת על תנאי אחד בלבד: מקור האמת היחיד הוא הריפו, וכל השאר אינו סוטה ממנו באופן בלתי מורגש. נפרט כיצד זה נסגר ב-ArgoCD וב-Flux, ומה יש לבדוק לפני הפעלת ההחלה האוטומטית.
מה נותן סנכרון אוטומטי של מצב האשכול
האפקט המרכזי — מצב האשכול מפסיק להיות תוצאה של פעולות ידניות. מניפסטים, מדיניות ופרמטרים של סביבות נמצאים בריפו כמקור האמת היחיד, והבקר משווה את המצב בפועל לזה המתואר ומביא את הפערים לצורה הרצויה.
סנכרון אוטומטי ב-Kubernetes מסיר את שכבת הביניים «המהנדס נזכר ותיקן»: שינוי נכנס לאשכול רק לאחר שעבר ריוויו ותועד בקומיט.
מכאן האפקט המדיד הראשון — זמן ההתאוששות. בעבר אובדן node, כשל בעדכון או סביבה הרוסה משמעותם הייתה בירור ידני: להיזכר מה ומתי הוגדר, למצוא את הקונפיגורציות העדכניות, לחזור על השלבים בסדר הנכון. כעת ההתאוששות מסתכמת בפריסה מהריפו, והספירה היא בדקות במקום בשעות.
אותו מנגנון סוגר מחלקה שלמה של כשלים בגלל תיקונים לא מתועדים — אלה שהוכנסו ישירות לאשכול ואיש אינו זוכר. הבקר מזהה דריפט כזה בעת ההשוואה הבאה, ואז או מחזיר את האובייקט למצב המתואר, או מסמן אותו כפער הנראה בממשק.
חזרה אחורה של ריליס הופכת לצפויה. שחרור מוחזר אחורה לא באמצעות אוסף פקודות ידניות תחת לחץ, אלא בקומיט הפוך: המצב המתואר הקודם מוחזר, והבקר בעצמו מביא את האשכול אליו, כולל מחיקת אובייקטים מיותרים. אנו מגדירים זאת מראש ובודקים בסביבת אימון, ולא ברגע התקלה.
לבסוף, בקרת השינויים מפסיקה להיות תלויה במשמעת. היסטוריית הקומיטים מראה מי שינה מה ומדוע, כל תיקון מקושר לריוויו, והפער בין הריפו לאשכול נראה כמדד ולא כהפתעה בריליס הבא.
השוואה בין מצבי סנכרון האשכול עם הריפו
מצב הסנכרון קובע מי ומתי מחיל שינויים מהריפו על האשכול. ל-ArgoCD ול-Flux סט המצבים זהה: החלה אוטומטית לפי קומיט, החלה אוטומטית עם התאוששות עצמית, אישור לפני פריסה והרצה לפי לוח זמנים. ההבדל הוא רק במה שקורה לתיקון ידני באשכול ולקומיט שגוי.
בדרך כלל המצב מוצמד לסביבה: ענף הפיתוח — לקו הפיתוח עם אוטומציה מלאה, ענף הריליסים — לסביבת הפרה-פרודקשן, תג או ענף נפרד — לפרודקשן עם אישור. זה מתקיים היטב באשכול אחד, כי המצב נקבע ברמת האפליקציה ולא של האשכול כולו.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| סנכרון אוטומטי עם התאוששות עצמית | קווי פיתוח ובדיקות שבהם דריפט אינו קביל | תיקון ידני מוחזר אחורה תוך דקות, קומיט שגוי נפרס מיד |
| סנכרון אוטומטי בלי התאוששות עצמית | סביבות שבהן מהנדסים מתקנים משאבים ישירות | הפער מצטבר בשקט, נראה רק בדוח |
| סנכרון עם אישור לפני פריסה | פרודקשן וקווי רגולציה | ההחלה תלויה בתורן: המיזוג קיים, הפריסה לא |
| הרצה לפי לוח זמנים או לפי אירוע בריפו | קווים נדירים, חלונות לילה, מיגרציות כבדות | השהיה בין הקומיט להחלה — דקות ושעות |
| תצפית ללא סנכרון | אבחון, סקר מלאי, קבלת אשכול של אחר | אינו מכניס שינויים לאשכול, אין כתיבה חזרה |
המגבלות כאן חשובות יותר מהיכולות: האוטומציה מזרזת פריסה רק כאשר לפני המיזוג לריפו עוברות בדיקות קונפיגורציה.
שלבי ההטמעה: אבחון, סכימה, הגדרה, בדיקה, מסירה
את העבודה אנו מבצעים בשלבים: מסקר מלאי של המצב הנוכחי ועד למסירה לתחזוקה. סנכרון אוטומטי של Kubernetes הוא החלפת מודל העבודה עם האשכול, ולא מתג, ולכן כל שלב נשען על התוצרים של השלב הקודם.
- אבחון האשכול. אוספים מלאי של אובייקטים, ומסמנים בנפרד את מה שנוצר ביד ואת מה שמנוהל מחוץ לריפו. הפערים האלה הופכים למועמדים הראשונים להבאה למצב המתואר.
- סכימת הסנכרון. מגדירים גבולות: אילו קווים מנוהלים מ-Git, אילו נשארים ידניים, היכן נדרשים ענפים נפרדים לפי סביבה. מתאמים את מודל הגישה ואת סדר החלת השינויים.
- הכנת הריפו. מניחים את המניפסטים לפי ספריות, מוציאים החוצה את פרמטרי הסביבות, מחברים בדיקות בשלב הקומיט — כך השגיאה נתפסת עוד לפני ההגעה לאשכול.
- הגדרת הבקר. פורסים ArgoCD או Flux במצב תצפית: ההחלה האוטומטית כבויה, ורואים רק את הפער בפועל מול הריפו.
- בדיקה על סטנד. מריצים תרחישים: תיקון מניפסט, חזרה אחורה, ריפו לא זמין, שינוי ידני ישירות באשכול. בודקים תוך כמה זמן המצב מתכנס ואיך הבקר מתנהג תחת עומס.
- מעבר למצב אוטומטי. תחילה קווים לא קריטיים, אחר כך השאר. מחיקת אובייקטים שאינם בריפו מופעלת אחרונה — כשרשימת המלאי התאימה למצב בפועל.
- מסירה לתחזוקה. מוסרים את הסכימה, את נוהל השינויים ואת מערך הבדיקות, ומכשירים את הצוות — מכאן והלאה השינויים נעשים בקומיט רגיל.
קונפיגורציות, סכימות ונוהלים בתוצרי הפרויקט
פרויקט נסגר לא במצגת, אלא במערך תוצרים שבהם משתמשים בלי מעורבות שלנו. להלן מה שנשאר אצל הלקוח לאחר הגדרת סנכרון אוטומטי של האשכול עם Git: קונפיגורציה עובדת, סכימת קשרים, הרשאות ונוהלים שלפיהם צוות התחזוקה עובד באופן עצמאי.
- קונפיגורציות עובדות. מניפסטים של אשכולות ושל אפליקציות ב-Git, מסודרים לפי סביבות; ההבדלים ביניהם מוצאים לקבצי ערכים נפרדים, ולא מועתקים לכמה ענפים.
- סכימת הסנכרון. איזה ריפו מקושר לאיזה אשכול, אילו מדיניות מוחלות בעת פער — מחיקת אובייקטים מיותרים, הבאה אוטומטית למצב שב-Git — והיכן נגמר אזור השינויים הידניים.
- מטריצת תפקידי גישה. מי מתקן מניפסטים, מי מאשר מיזוג, למי יש הרשאות על סודות, ולמי יש גישה לאשכול לקריאה בלבד.
- נוהל חזרה אחורה. סדר צעד-אחר-צעד לחזרה למצב הקודם: ביטול קומיט, סנכרון, בדיקת התוצאה — בציון כמה זמן דורשת הפעולה.
- אופן העבודה עם סודות. היכן הם נשמרים, כיצד מסובבים אותם, מה עושים בעת חשיפה; תיקונים ישירות באשכול נשללים כקטגוריה.
- תיעוד לתחזוקה. מה לעשות בעת פער, בעת אי-זמינות של בקר הסנכרון, כיצד לחבר סביבה חדשה או אשכול חדש.
- אותות והתראות. אילו מדדי מצב סנכרון נאספים, באילו ערכים מגיעה התראה לתורן ומי מטפל בה.
הקבלה נעשית לפי אותה רשימה: פורסים סביבה מאפס בקפדנות לפי התיעוד, מכניסים בכוונה שינוי ידני ופער, ואחר כך בודקים אם החזרה אחורה עומדת בנוהל המוצהר.
מקרה בוחן: שחזור אשכול בדקות במקום בשעות
אשכול בשלוש סביבות — פיתוח, קדם-ריליס, פרודקשן — נשען על תיקונים ידניים: מהנדסים התחברו ישירות ושינו אובייקטים במקום. חלק מההגדרות כלל לא הגיע לריפו, וחלק היה בפער מולו.
השחזור לאחר עדכון כושל או כשל node ארך 4–6 שעות: פרסו מגיבוי, אחר כך הדביקו ידנית כל מה שהספיק להשתנות מאז נטילתו, והשוו בין הסביבות לפי זיכרון המשתתפים.
מה שינו
את תיאורי האובייקטים העבירו ל-Git כמקור האמת היחיד, ואת ההשוואה וההשלמה של המצב הפקידו בידי Argo CD: הוא משווה את האשכול לריפו לפי לוח זמנים ומחזיר בעצמו כל סטייה אחורה. הרשאות כתיבה לאשכול ניתנו רק לבקר הסנכרון, ולאנשים נותרו קריאה וטיפול בתקלות. שינויים כעת עוברים דרך בקשת מיזוג — עם ריוויו, היסטוריה וחזרה אחורה ברוויזיה אחת.
מדדים לפני ואחרי
- זמן ההתאוששות של סביבת הפרודקשן: 4–6 שעות → 12–20 דקות, וזאת בלי מעורבות של מהנדס תורן.
- שיעור השינויים שעברו שלא דרך הריפו: כשליש → פחות מ-2%, וגם זה רק תיקונים חד-פעמיים בעת תקלה.
- פערי קונפיגורציה בין הסביבות: כמה תקלות בחודש → אף אחת ברבעון.
נעלמה מחלקה שלמה של כשלים — «תיקנו בפרוד ושכחו להעביר»: בעת פער מול הריפו האשכול חוזר למצב המתואר בעצמו, במקום להצטבר כ"פתית שלג" ייחודי שמפחיד לגעת בו.
האשכול כבר מוגדר, אבל ה-auto-sync kubernetes נכשל: מה עושים
קונפליקט סנכרון כמעט תמיד אינו מעיד על כשל של הבקר, אלא על שני מקורות אמת באשכול אחד. חלק מהאובייקטים מתוקן ביד — דרך לוח הבקרה, kubectl מקומי או סקריפטים של ריליס — וחלק מגיע מהריפו.
כשההתאוששות העצמית מופעלת, הבקר מחזיר בשקט את הגרסה שלו, והתיקון הידני נעלם; בלעדיה האפליקציה נשארת בפער, וה-auto-sync kubernetes לא עובר.
לאשכול שכבר פרוס, הצעד הראשון הוא סקר בעלות: לפי המטא-דאטה של הקונפיג שהוחל לאחרונה ול-annotations של מעקב, רואים אילו שדות הוגדרו ידנית ואילו אובייקטים כלל לא נוצרו מהריפו. בדרך כלל צפים משאבים שתוקנו בזמן תקלה ונשכחו מלהעביר ל-Git.
מכאן — מעבר הדרגתי, בלי מחיקה חד-פעמית של הפערים. תחילה הבקר (ArgoCD או Flux) פועל במצב השוואה: מציג את ההבדל, אך אינו מחיל דבר. אחר כך מיגרציה של קונפיגורציות — מניפסטים חיים נלקחים מהאשכול, ומהם מוסרים שדות שהאשכול עצמו מייצר.
לאחר מכן מופעל סנכרון אוטומטי בלי מחיקת אובייקטים שמחוץ לריפו, ורק כשהפער יציב על אפס — ניקוי והתאוששות עצמית.
הגבולות מתווים מראש: סודות, אובייקטים של אופרטורים ומאגרים המחוברים לחומרה אינם מועברים לריפו, והחריגים מוגדרים לפי נתיבים ספציפיים, ולא על ידי כיבוי השליטה על האובייקט כולו.
התוצאה — מצב האשכול נקרא שוב מהריפו, חזרה אחורה נעשית ברוויזיה אחת, וכל תיקון ידני או שנכנס ל-Git או נראה כסטייה.
ספקות טכניים: הרשאות, סודות וחזרות אחורה של שינויים
סנכרון אוטומטי נתקע לא בהתקנת הבקר, אלא בגבולות: מי יכול לשנות את מצב האשכול, היכן חיים נתונים רגישים ומה יקרה אם הקשר עם הריפו יאבד. להלן מה שמהנדסים שואלים לפני תחילת העבודה.
מי מקבל הרשאה לשנות את הפרוד דרך Git?
ההרשאות ניתנות בשכבות: מפתח דוחף לענף שלו, שינוי לענף הסביבה עובר בדיקה ואישור, והגישה הידנית לאשכול נסגרת. אחרת המצב ב-Git ובאשכול מתפצל — והסנכרון הבא מחזיר אחורה תיקון של מישהו אחר.
היכן נשמרים הסודות אם הכול מתואר בריפו?
סיסמאות ומפתחות גלויים לא נשארים ב-Git: או שמצפינים אותם לפני הקומיט, או שמושכים אותם ממאגר חיצוני ברגע ההחלה, ומשאירים בתיאור רק הפניה. הפענוח זמין לבקר הסנכרון ולמעגל מצומצם של מנהלים.
אפשר להפעיל את האוטומציה חלקית, ולא על כל האשכול?
כן, וזהו סדר הטמעה רגיל: החלה אוטומטית מפעילים תחילה בקו הבדיקות ובשירותים לא קריטיים, והפרודקשן עובד בהתחלה לפי אישור. גם סדר ההחלה ניתן להגדיר — תחילה תלויות, אחר כך שירותים, וסנכרון חלקי נראה שורה-שורה: אילו אובייקטים נותרו מאחור ובאיזו בדיקה נכשלו.
מה יקרה בכשל של שירות הסנכרון?
האשכול ממשיך לפעול במצב האחרון שהוחל — האפליקציות הפועלות אינן נעצרות, והשינויים מ-Git פשוט אינם מוחלים. לאחר שחזור הקשר הסנכרון מדביק את הפער, וההתראה על אובדן הקשר מגיעה לפני שהמשתמש יבחין בפער.
נדון במשימה: מה נדרש כדי להעריך את הסכימה שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים תצלום של הסכימה הנוכחית שלכם: כיצד בנויות הסביבות, למי יש הרשאה לשנות את האשכול, מה כבר מתואר באופן דקלרטיבי ומה נעשה ביד. להלן מה שמסיר את עיקר אי-הוודאות בעת ההערכה.
- הרכב הסביבות: כמה אשכולות ומרחבי שמות, במה שונים קווי הפיתוח, הפרה-פרודקשן והפרודקשן.
- סדר הפריסה הנוכחי: כיצד שינויים מגיעים היום לאשכול — פקודות ידניות, סקריפטים, צינור build, ובאיזה שלב התהליך נעצר לרוב.
- מה כבר בריפו: מניפסטים, תבניות, קונפיגורציות של סביבות, ואילו אובייקטים נותרו מחוצה לו.
- תפקידים והרשאות: מי מבצע קומיט, מי מאשר פריסה לפרוד, כיצד מונפקים פרטי הזדהות לסנכרון אוטומטי.
- מגבלות: מדיניות אבטחה, רג'יסטרים סגורים של אימג'ים, חלונות שינוי, קווים בלי גישה חיצונית.
- התנהגות יעד: סנכרון אוטומטי מלא או אישור לפרוד, האם נדרשת חזרה לגרסה הקודמת בפעולה אחת.
תארו את המשימה בצורה חופשית — זה מספיק כדי לחזור עם הערכה ותוכנית. סכימת הסביבות או דוגמה של התהליך הנוכחי יזרזו את הניתוח: מהם רואים היכן הסנכרון ייתן אפקט מיד, והיכן יידרש מעבר הדרגתי.