פיתוח מניפסטים של Kubernetes: Deployment, Service, Ingress, Secret

למה מניפסטים של kubernetes נשברים בעת scaling

פריסה שעברה בקונטור הבדיקות בלי הערות נופלת בפרודקשן כבר בשלב הראשון. פורמלית אלה אותם מניפסטים של kubernetes מה-repository, אבל ה-cluster מחזיר שגיאה: ה-limits לא תואמים את העומס בפועל, ה-selectors של Service לא מוצאים pods, וה-Ingress מצביע על class שלא קיים בסביבה הזו. הכשל בפריסה נראה כמו מקריות, למרות שהסיבה הצטברה מראש.

הפער בין הסביבות מתחיל בפרטים קטנים. בקונטור הבדיקות יש פחות replicas, ה-limits רכים יותר, ה-Secret מורכב מקבוצה אחרת של מפתחות, וכללי ה-Ingress מצומצמים ל-host אחד.

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

מכאן מופיעים תיקונים ידניים במשאבים. מישהו מתקן limits ישירות ב-cluster כדי לסגור תקלה, מישהו מוסיף annotation, מישהו מחליף image לקודם. ה-cluster הופך למקור האמת היחיד, וה-repository — לעותק מיושן.

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

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

אפקטים מדידים של קונפיגורציה מנוהלת

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

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

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

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

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

אפשרויות לתיאור משאבים: השוואת גישות

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

האלטרנטיבות שביניהן באמת בוחרים:

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

סדר ההטמעה: מאפיון עד מסירה

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

1. אפיון משאבים. אוספים את המצב בפועל של ה-cluster: אילו Deployment, Service, Ingress ו-Secret קיימים, מה נוצר ידנית, איפה כפילויות, איך מוגדרים limits ו-probes. בפלט — מפת משאבים עם סימון מה עובר לתיאור דקלרטיבי ומה יוצא משימוש.
2. סכמת סביבות. מסמנים את הקונטורים ואת ההבדלים ביניהם: אילו ערכים מוצאים בנפרד, מה נדרס ב-overlay, איפה נשמרים secrets. זה מסיר את העתקת המניפסטים בין הסביבות ואת הפערים שמצטברים בתיקון ידני.
3. הגדרת מדיניות. קובעים כללי שמות ותוויות, requests ו-limits למשאבים, הפרדת הרשאות ובדיקת מניפסטים לפני application — ב-repository ובכניסה ל-cluster, לפי חישוב לאחר אפיון.
4. בנייה ו-review של מניפסטים. מתארים Deployment, Service, Ingress ו-Secret כקבצים מנוהלי-גרסאות, מריצים בדיקות סטטיות ו-review של שינויים: תיקון קונפיגורציה עובר את אותו מסלול כמו הקוד.
5. בדיקה בקונטור הבדיקות. פורסים את הסט המלא בסביבת הבדיקות, בודקים עדכון ללא downtime, rollback ל-revision הקודמת והתנהגות כשצומת אינו זמין. שגיאות קונפיגורציה נתפסות כאן, ולא בקונטור הפרודקשן.
6. מסירת התחזוקה. מוסרים את ה-repository, תיאור סכמת הסביבות ותקנון השינויים, ומלמדים את הצוות: איך מוסיפים שירות, איך מוציאים ומבצעים rollback ל-release, ולאן להסתכל בעת תקלה.

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

מארז האספקה: קונפיגורציות, סכמות, מדיניות גישה

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

• תיאורי משאבים — Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler: מסודרים בתיקיות בלי כפילויות, עם הערות לפרמטרים לא טריוויאליים — אסטרטגיית עדכון, readiness probes, requests ו-limits.
• סכמת סביבות — אילו namespaces קיימים, במה dev שונה מ-stage ומ-prod, איפה חיים משאבים משותפים ואיך מופרדות קונפיגורציות בין הקונטורים.
• מדיניות גישה — תפקידי RBAC ו-bindings, כללי בידוד רשת בין שירותים, מכסות ל-namespace: מתואר מי ומה יכול לשנות ב-cluster.
• ניהול secrets — מאיפה מגיעים הערכים, איך נכנסים ל-cluster, איך מסובבים (rotation) ולמי יש הרשאת קריאה.
• תקנון עדכון — סדר הפריסה, ניהול גרסאות של images, תנאי rollback ל-revision הקודמת והתנהגות המערכת בעדכון כושל.
• תיעוד — תיאור קצר של הארכיטקטורה, הוראות פריסה ותפעול טיפוסי: אבחון pod, scaling, חיבור שירות חדש.

מקרה בוחן: זמן הפריסה וסוג הכשלים שנמנעו

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

מה הראה האפיון

מחצית הכשלים — drift של קונפיגורציה: תיקונים שנעשו ישירות ב-cluster חיו במקביל לקבצים וסתרו אותם. רבע — היעדר readiness checks, שבגללם תעבורה הגיעה לשירות שעוד לא עלה. השאר — secrets עם ערכים שונים בסביבת הפיתוח ובפרוד.

מה שינינו

התיאורים עברו ל-repository, ערכים משותפים הופרדו מהערכים הסביבתיים, וה-secrets — למאגר מנוהל בקישורים במקום עותקים. הוספנו readiness ו-liveness checks, הפריסה הפכה מדורגת עם עצירה אוטומטית בסטייה של מדדים, וה-rollback — לחזרה של סט התיאורים הקודם. זמן ה-release התקצר מ-40–50 דקות ל-6, והחזרה למצב הקודם — לדקה ולפעולה אחת.

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

במה תיאור דקלרטיבי של משאבים שונה מתיקון ידני ב-cluster?

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

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

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

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

ספקות טכניים נפוצים בנוגע למניפסטים של kubernetes

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

אפשר להעביר את הפרודקשן בלי downtime?

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

הסביבות התפצלו — הבדיקות לא משחזרות את הפרודקשן?

את הפערים מסירים בבסיס תיאורים משותף: הסטנדים נבדלים רק בפרמטרים — מספר העותקים, limits, כתובות — ולא במבנה ה-objects. השוואה אוטומטית ב-build תופסת את ה-drift מיד, ולא כעבור חודש.

מה יקרה לתפקידים ולמדיניות הגישה הקיימים?

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

נדון במשימה: סדר תחילת העבודה

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

• רשימת הסביבות וה-clusters: dev, stage, prod, הבדלים ב-namespaces, ב-limits של משאבים ובמדיניות גישה.
• איך ה-deploy בנוי היום: application ידני, pipeline, Helm או ניהול דקלרטיבי מה-repository — מזה תלוי ישירות היקף העבודה.
• דרישות ל-secrets ולקונפיגורציה: מאיפה מגיעים הערכים, האם נדרשת אינטגרציה עם מאגר חיצוני, מי ואיך מקבל גישה.
• מעגל הרשת: דומיינים, תעודות, כללי ניתוב, מי מנפיק אותם ואיך הם מתעדכנים.
• דרישות לעדכונים ול-rollback: אסטרטגיית פריסה, readiness checks, חלון אי-זמינות מותר של השירות.
• מי מטעם הלקוח מאשר החלטות וכמה מהר זמינים הסטנדים לבדיקה.

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