מדוע פריסה מדורגת שוברת את הפרודקשן: צווארי בקבוק ללא מפעיל
פריסה מדורגת (canary) ידנית נשענת על אדם: מהנדס פותח פאנל, משנה את חלק התעבורה, מסתכל על הגרפים ומחליט אם להמשיך או לבצע rollback. כל עוד השחרורים נדירים, זה עובד.
ברגע שנכנסים לפרודקשן כמה שינויים ביום, בין שינוי התעבורה לתגובה נוצר חלון של דקות, וכל הזמן הזה הגרסה התקולה חיה על משתמשים אמיתיים. גם ה-rollback ידני: עד שמישהו נזכר בפקודה ומחזיר את התמונה הקודמת, חלק מהבקשות כבר קיבלו שגיאות.
הבעיה השנייה — המדדים אינם מקושרים לשחרור. אוסף המדדים רואה גרף שגיאות כללי של השירות, אך אינו יודע שדקה קודם נפרסה גרסה חדשה. זינוק של שגיאות 500 בגרף אינו ניתן להבחנה מרעש רקע או מתקלה של מישהו אחר, וההחלטה מתקבלת לפי אינטואיציה ולא לפי נתונים. הנראות (observability) של השחרור מתפרקת: לא ברור אם ההידרדרות הגיעה עם הבילד החדש או הייתה לפניו.
צוואר הבקבוק השלישי — החלפת תעבורה עיוורת. המשקל בין הגרסה הישנה לחדשה משתנה ביד, ללא קישור להתנהגות בפועל תחת עומס. אם הגרסה החדשה שומרת על השהיה תקינה ב-5% מהתעבורה, אך נשברת ב-50%, יגלו על כך רק לאחר ההחלפה המלאה.
מפעיל Flagger Kubernetes סוגר את כל שלושת הפערים: הוא עצמו מנהל את הפריסה המדורגת לפי השלבים שהוגדרו, הוא עצמו אוסף מדדים משתי הגרסאות ומשווה ביניהם, ובחריגה מהספים מפעיל rollback אוטומטי של השחרור ללא מעורבות תורן. מפרקים כיצד זה בנוי ומה צריך להגדיר כדי שהמפעיל יקבל החלטות נכונות.
מה מספקת אספקה פרוגרסיבית מבוקרת
אספקה פרוגרסיבית מפסיקה להיות טקס ידני כאשר מפעיל מנהל אותה: Flagger בעצמו מזיז תעבורה בין גרסאות לפי מדדים מוגדרים ומבצע rollback לשחרור אם המדדים חורגים מהסף. המהנדס מתאר את המצב הרצוי במניפסט, ומכאן ואילך המערכת שומרת עליו ללא מעורבות תורן.
מה משתנה בנתונים
שיעור ה-rollback יורד לא מפני שהשחרורים נעשו זהירים יותר, אלא מפני שהבעיה נתפסת על 5% מהתעבורה ולא על כל הפארק. סוג הכשל "העלינו וגילינו מפניות" נעלם: שלב הקנרית נעצר לפי מדד שגיאות או השהיה, והגרסה מבוצעת בה rollback אוטומטית.
זמן ההתאוששות של השירות מתקצר משעות של ניתוח ידני לדקות — את ה-rollback יוזם המפעיל עצמו לפי נתונים נצפים, ולא אדם לפי שיחה טלפונית.
עלות ההשבתה יורדת בזכות כך ששחרור תקול לא מגיע לקהל הראשי. שחרור מבוקר מספק צפיות: שלבי ההעלאה, ההשהיות ותנאי הקידום קבועים בקונפיגורציה, ולא בראשו של האחראי. היציבות של ההעלאה מפסיקה להיות תלויה במי שנמצא היום במשמרת.
מדוע זה עובד
המפעיל כל הזמן משווה את המדדים בפועל של השירות לספים ומקדם תעבורה רק כאשר הם נשמרים. אם המדדים מתדרדרים — החזרה לגרסה הקודמת מתרחשת ללא פקודות ידניות. זה מסיר את המקור העיקרי להשבתות ארוכות: ההשהיה בין הופעת הבעיה לתגובת האדם.
מצבי אספקה פרוגרסיבית: השוואת גישות
האופרטור Flagger מנהל את ההשקה דרך אובייקט Canary: בו מוגדרת האסטרטגיה, שלבי הקידום והמדדים שלפיהם מתקבלת ההחלטה להעביר תעבורה לגרסה החדשה. האסטרטגיה קובעת כיצד בדיוק מתחלקת התעבורה בין הגרסאות ומה קורה כאשר המדדים חורגים — מחזרה אוטומטית ועד השהיה עם אישור ידני. להלן השוואה בין המצבים לפי תנאי היישום והמגבלות.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| שחרור קנרי | נדרשת בדיקה הדרגתית על תעבורה אמיתית: 5–10% מהבקשות עוברות לגרסה החדשה, המדדים נבדקים בכל שלב | דורש איסוף מדדים (הצלחה, השהיה) ושתי גרסאות פרוסות בו-זמנית; בעת אנומליה התעבורה חוזרת, אך חלק מהמשתמשים כבר נפגעו |
| פריסה כחול-ירוק | שירות קריטי שבו עבודה משולבת של גרסאות אינה קבילה; החלפת התעבורה כולה לאחר בדיקה | נדרשים משאבים כפולים בזמן ההשקה; החזרה מיידית, אך הבדיקה מתבצעת בסביבת בדיקות ולא על תעבורה חיה |
| שיקוף תעבורה | רוצים לבדוק את הגרסה החדשה על עותק של בקשות אמיתיות בלי להשפיע על המשתמשים | התשובות של הגרסה המשכפלת נזרקות, יש לבודד תופעות לוואי (כתיבה למסד נתונים, קריאות חיצוניות) |
| אישור ידני | שינויים רגולטוריים או בסיכון גבוה, שבהם ההחלטה מתקבלת בידי אדם | האוטומציה נעצרת בהשהיה וממתינה לאישור — ההשקה לא תסתיים בלי השתתפות האופרטור |
לא ניתן לשלב מצבים באובייקט אחד: Flagger מיישם אסטרטגיה אחת לכל שחרור. בפועל משתמשים בשיקוף כשלב ראשון לפני שחרור קנרי, ואת האישור הידני מוסיפים כהשהיה סופית. בחירת המצב קובעת כמה גרסאות להחזיק בו-זמנית וכיצד להגדיר את איסוף המדדים — מכך תלוייה מהירות החזרה.
כיצד אנו מטמיעים את Flagger Kubernetes operator
הטמעת האופרטור מתחילה בביקורת של תהליך השחרור הנוכחי: בודקים כיצד הגרסה מגיעה לפרודקשן, מי ומה נבדק ידנית, והיכן החזרות לאחור (rollback) אורכות הכי הרבה זמן.
בשלב זה מזהים את נקודות הכשל — בדיקות ידניות, היעדר מדדים, שחרורים "בעיוורון" — וקובעים אילו שירותים יעברו ראשונים לאספקה הדרגתית.
- ביקורת תהליך השחרור. מפרקים את התהליך הנוכחי: אסטרטגיית העדכון, זמן החזרה לאחור, מי מקבל את ההחלטה על הקידום. התוצר — מפת שירותים וסדרי עדיפויות: היכן אספקה הדרגתית מניבה את האפקט המרבי, והיכן די בהרצת קנרית על שירות אחד.
- תרשים מדדים וספים. קובעים לפי אילו אותות האופרטור מחליט לקדם או להחזיר גרסה לאחור: שיעור שגיאות, השהיית תגובה, רוויה של משאבים. את הספים מגדירים לפי ההתנהגות בפועל של השירות, ולא "לפי העין" — אחרת האופרטור יחזיר לאחור גרסאות יציבות.
- הגדרת האופרטור. מתקינים את Flagger Kubernetes operator באשכול, מתארים משאבים קנריים, מקשרים את מקור המדדים ואת כללי הניתוח. בנפרד מגדירים את שלבי הקידום: כמה תעבורה עוברת לגרסה החדשה, כמה זמן נמשכת ההשהיה, ובאילו תנאים מופעלת החזרה לאחור אוטומטית.
- בדיקה על סביבת הבדיקות. מריצים תרחישים על קונטור הבדיקות: שחרור מוצלח, הידרדרות לפי מדדים, כשל מלא. מוודאים שהחזרה לאחור מחזירה את התעבורה לגרסה הקודמת ללא התערבות ידנית, ושההתראות מגיעות למקום שבו יראו אותן.
- העברת נהלים. מוסרים לצוות תיאור של התהליך: כיצד לשחרר גרסה, כיצד לקרוא את הסטטוס של ההרצה הקנרית, ומה לעשות כאשר החזרה לאחור הופעלה. בנוסף — תיעוד של התצורה, כדי ששינויים בספים לא ידרשו אותנו.
סדר פעולות כזה סוגר את הסיכון המרכזי — אוטומציה לשם אוטומציה. תחילה מודדים, אחר כך מגדירים, אחר כך בודקים על סביבת הבדיקות, ורק לבסוף מעבירים לצוות. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
ארטיפקטים: קונפיגורציות, סכמות ותקנונים
אנחנו מעבירים לא "גישה לקלאסטר", אלא ערכה שלמה שלפיה הצוות שלכם יוכל ללוות מהדורות בלעדינו. כל ארטיפקט מקושר לריפוזיטורי ועובר ריוויו בדיוק כמו קוד האפליקציה.
- מניפסטים של האופרטור Flagger: תעלות (canary) ו-blue-green לכל שירות, חיבור ל-ingress או ל-service mesh, פרמטרים של שלבים — נתח התעבורה, השהיה בין שלבים, מספר איטרציות הניתוח.
- סכמת תעבורה: דיאגרמת ניתוב primary/canary, נקודות מדידת מטריקות, חיבור לדאשבורד — רואים לאן הולך נתח הבקשות בכל שלב.
- מדיניות גישה: תפקידים וחשבונות שירות של האופרטור, הרשאות קריאת מטריקות וכתיבה למרחבי שמות יעד, הגבלות לפי namespace, אינטגרציה עם ספק האימות שלכם.
- קונפיגורציית ניתוח: סט מטריקות הצלחה (שיעור שגיאות, השהיה, רוויה), ספים וחלון תצפית, התנהגות בעת חוסר בנתונים.
- תיעוד המהדורה: איך מופעלת ההשקה, איך קוראים את הסטטוס, אילו התראות מגיעות בעת כשל בניתוח, צ'ק-ליסט לפני ההתחלה.
- תקנון rollback: תנאים ל-rollback אוטומטי, rollback ידני לפי פקודה, סדר הודעה לאחראים, תחקור תקלה afterwards.
- הוראות ליווי: הוספת שירות חדש, שינוי ספים, עדכון האופרטור, שגיאות טיפוסיות והסיבות שלהן.
הכול נאסף לריפוזיטורי של תשתית עם תיאור ב-README, כך שמהנדס חדש בצוות יפרוס את ההשקה לפי המסמך, ולא לפי הזיכרון של העמיתים.
מקרה בוחן: כיצד צומצמו כשלים ב-70% בזכות אופרטור
לפני: פריסות והחזרות ידניות "בעין"
שירות בן 40+ מיקרו-שירותים, שחרורים פעמיים ביום, כל פריסה — ידנית: מהנדס הפעיל עדכון, הסתכל על גרפים בלוח המחוונים התורן והחליט אם להשאיר את הגרסה החדשה. שיעור ההחזרות עמד על 18% מכלל השחרורים, והזמן הממוצע מזיהוי הבעיה ועד החזרה לגרסה הקודמת — כ-25 דקות. בזמן הזה הספיקו להצטבר 4-6 שגיאות בלוגים ותלונות מהמשתמשים.
מה שינו
פרסו את Flagger כאופרטור באשכול והעבירו את הפריסות לתרחיש קנרית עם ניתוח אוטומטי של מדדים. האופרטור עצמו מעלה גרסה קנרית, מפנה אליה חלק מהתעבורה וכל 30 שניות משווה מדדים מרכזיים — שיעור שגיאות, השהיית תגובה, הצלחת בקשות — לערכי הסף.
אם מדד חורג מהגבול, ההחזרה מתרחשת ללא מעורבות אדם: התעבורה חוזרת לגרסה היציבה, הפודים הקנריים נמחקים, אירוע נשלח למערכת הניטור.
את הספים וחלון הניתוח התאימו לפרופיל השירות: עבור נתיבים קריטיים — גבולות מחמירים לשגיאות, עבור משימות רקע — רכים, עם חלון תצפית ארוך יותר. זה הסיר התראות שווא, שבגללן קודם לכן המהנדס התורן כיבה את האוטומציה וחזר לשליטה ידנית.
תוצאה
שיעור ההחזרות ירד מ-18% ל-5% — בכ-70%. הזמן הממוצע לחזרה לגרסה יציבה הצטמצם מ-25 דקות ל-40 שניות: האופרטור מגיב לחריגה במדד לפני שהתורן מספיק לפתוח את לוח המחוונים. העומס על הצוות ירד — שחרורים מתבצעים ללא השגחה מתמדת, המהנדסים מתחברים רק לניתוח הסיבות, ולא להחזרה עצמה.
אפקט נפרד — צפיות הפריסות. כאשר ההחזרה אוטומטית ומהירה, הצוות מפסיק לפחד משחרורים תכופים: מספר הפריסות גדל, ומספר התקריות לשחרור ירד. מדדי השחרור מתועדים כעת בהיסטוריית האופרטור, ולפיהם ניתן לראות איזו גרסה ובאיזה סף הוחזרה — זה מאיץ את הניתוח.
במה Flagger שונה מאמצעי הפריסה הסטנדרטיים?
אמצעי Kubernetes הסטנדרטיים — Deployment עם RollingUpdate, סקריפטים ידניים ב-CI, kubectl set image — מנהלים רק את אספקת הגרסה החדשה. הם אינם עונים על השאלה המרכזית: האם זו הגרסה שכדאי להשאיר בפרודקשן.
מישהו צריך להסתכל ידנית על הגרפים, להשוות מדדים ולהחליט אם להמשיך את הפריסה או לבצע רולבק. בעשרות שחרורים בשבוע ההחלטה הזו מתקבלת לפי העין ומאחרת בדקות.
Flagger — אופרטור שסוגר את המעגל: הוא לא רק פורש, אלא בעצמו מנתח את התנהגות הגרסה החדשה ומבצע לה רולבק אם המדדים חרגו מהספים. האופרטור מרים תרחיש קנרית או blue-green, מעביר בהדרגה את חלק התעבורה לגרסה החדשה ובכל שלב מתשאל את מערכת הניטור — שיעור שגיאות, השהיות, רוויה.
כל עוד הערכים בטווח התקין, המשקל גדל; עם החריגה מהגבול התעבורה חוזרת לגרסה היציבה אוטומטית, בלי מהנדס תורן.
ההבדל מתגלה ברגע הכשל. סקריפט ידני ייעצר במקום שבו יעצור אותו אדם — אבל האדם הזה יכול באותו זמן לישון או לטפל בתקרית אחרת. האופרטור מגיב תוך שניות ולפי כלל שהוגדר מראש: כמה שגיאות נחשבות לסף חירום, כמה פעמים ברצף המדד צריך לחרוג ממנו לפני ביצוע רולבק. זה הופך את הרולבק מהחלטה "לפי העין" לנוהל משוחזר.
יש גם קו שני של הבדלים — יכולת השליטה. האמצעים הבסיסיים לא יודעים להחזיק כמה תרחישים במקביל, לתאם אותם עם מדיניויות ולהשאיר עקבה לניתוח. האופרטור מתואר באופן דקלרטיבי, שומר היסטוריה של פריסות וסטטוסים, ולכן ניתוח התקרית מתבצע לפי עובדות ולא לפי זיכרונות. דווקא הניתוח האוטומטי של מדדים ורולבק לפיהם — זה מה שחסר לאמצעים הסטנדרטיים.
ספקות טכניים נפוצים בעת הטמעה
Flagger הוא אופרטור Kubernetes שמנהל פריסה באמצעות משאבים מותאמים אישית: הוא נרשם לשינויים באשכול ומחליף תעבורה בין גרסאות לפי כללים מוגדרים.
לכן, הדבר הראשון שאנו בודקים בהתחלה הוא תאימות לאשכול הנוכחי: איזו גרסת API קיימת, האם יש הרשאות ליצירת CRD ולעבודה עם ingress controller או service mesh. אם האשכול מנוהל וחלק מההרשאות חסומות, אנו בונים את תוכנית הפריסה דרך נקודות כניסה זמינות, ולא שוברים את הארכיטקטורה הקיימת.
הספק השני הוא ההשפעה על העומס. האופרטור אינו משמש כפרוקסי ואינו מוסיף שכבה משלו לנתיב הבקשה: הוא רק משנה משקלי ניתוב ועוקב אחר מדדים. עלויות התקורה מצטמצמות לסקרים תקופתיים של מדדים ולחישוב מחדש של משקלים, ולא לעיבוד כל בקשה.
השלישי הוא הדרישות למדדים. לצורך rollback אוטומטי נדרשים אותות מדידים: שיעור שגיאות, השהיה, רוויה. אם אין מדדים, הפריסה מתבצעת באישור ידני — זהו מצב עבודה תקין, אך ללא rollback אוטומטי.
מה יקרה אם באשכול אין service mesh או ingress מתקדם?
Flagger יודע לעבוד גם עם בקרים בסיסיים דרך מנגנוני ניתוב זמינים. בשלב הבדיקה אנו בוחנים אילו נקודות החלפת תעבורה קיימות באשכול שלכם, ומתאימים את מצב הפריסה אליהן — ללא בנייה מחדש של כל התשתית.
עד כמה קשה לתחזק תוכנית כזו בהמשך?
העבודה העיקרית היא להגדיר פעם אחת את כללי הפריסה ואת ספי המדדים, לאחר מכן האופרטור פועל בעצמו. התחזוקה מצטמצמת לעדכון הספים בעת שינוי בפרופיל העומס ולפיקוח שהמדדים יישארו מהימנים.
האם ניתן לבצע rollback אם הגרסה החדשה מתנהגת באופן לקוי?
כן, rollback הוא תרחיש שגרתי: כאשר המדדים חורגים מהסף, האופרטור מחזיר את התעבורה לגרסה הקודמת באופן אוטומטי. בנוסף, אנו מגדירים אישור ידני לשירותים קריטיים שבהם אוטומציה אינה רצויה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שההערכה תהיה מציאותית ולא "לפי תחושה", עלינו להבין את מערך האספקה הנוכחי שלכם: כיצד בנוי האשכול, מי וכיצד מפרסם מהדורות, האם קיים כבר service mesh או ingress controller שמסוגל לנהל תעבורה.
מהפרטים הללו תלוי אם נתקין את Flagger מעל mesh קיים או שנקים שכבת canary מאפס, ואילו מדדים ישמשו כטריגרים לחזרה לאחור.
לאחר מכן נבהיר את התהליך: כמה שירותים נמצאים באזור השינויים, באיזו תדירות אתם מפרסמים מהדורות, מי מקבל את ההחלטה על קידום — אדם או אוטומציה לפי מדדים. זה קובע את עומק ההגדרה: מפריסה canary בסיסית ועד מיתוג blue-green עם הזזת תעבורה הדרגתית.
אם קיימות דרישות נוקשות לגבי חלונות פרסום או תיאום עם העסק, נכלול אותן במדיניות הפריסה כבר מלכתחילה, ולא לאחר התקרית הראשונה.
מה נדרש מכם כדי שנחזור עם תוכנית:
- גישה לתיאור האשכולות ולסכימת האספקה הנוכחית — מאגרי קונפיגורציה, מניפסטים, סכימות סביבות;
- רשימת שירותים מועמדים והקריטיות שלהם: מה ניתן לפרוס כ-canary ומה דורש חזרה לאחור מיידית;
- מדדים שלפיהם אתם כבר מקבלים החלטות — השהיה, שיעור שגיאות, רוויה — והיכן הם נאספים;
- תהליך המהדורות הנוכחי: מי מפרסם, מי מאשר, אילו שלבים ידניים קיימים כעת;
- דרישות לחזרה לאחור: תוך כמה זמן המערכת צריכה לחזור לגרסה הקודמת ומי מפעיל זאת;
- מגבלות גישה ואבטחה: אילו תפקידים יש לצוות, מה ניתן לשנות באשכול.
בסיום השיחה נחזור עם הערכת עבודה, טיוטת תוכנית הטמעה לפי שלבים ורשימת סיכונים שאנו רואים בתשתית שלכם. תארו את המשימה בצורה חופשית — מה כואב כעת ואיזו תוצאה נדרשת — ואנו נשאל שאלות הבהרה ונציע את הצעדים הבאים.