Kyverno ב-Kubernetes: מדוע המדיניות לא פועלות
ברוב המקרים המדיניות קיימת פורמלית: המניפסטים הוחלו, הכללים מתוארים, הדוחות נאספים. אבל חלק מהפריסות עוברות מתחת לרדאר הבדיקות, חלקן נופלות עם שגיאה לא ברורה של וובהוק admission, והקונפיגורציה של הקלאסטר בין הסביבות הולכת ומתפצלת. הסיבה כמעט אף פעם אינה בכללים עצמם — היא באופן שבו ההחלה שלהם מוגדרת.
המקור הראשון — וובהוק ה-admission עצמו. אם נבחר עבורו מצב שבו אי-זמינות של קונטרולר המדיניות אינה חוסמת את הבקשה, פריסות באותו רגע עוברות בלי בדיקה. לאותה קטגוריה שייכים גם סלקטורים לפי מרחבי שמות ותוויות: תחת הכלל נופל רק חלק מעומסי העבודה. ופודים שהקונטרולרים יוצרים כבר אחרי הבדיקה נשארים מחוץ למדיניות ללא סריקה ברקע.
השני — סדר הפעולה של כללי המוטציה ומדיניות הוולידציה. המוטציה משנה את האובייקט לפני הוולידציה, ולכן בדיקה שמכוונת לשדות שמזריע כלל אחר מתנהגת אחרת מהצפוי. פריסות שנדחו מגיעות עם הודעה של הוובהוק בלי שם הכלל ובלי השדה הספציפי — מטקסט כזה אי אפשר לשחזר את הסיבה.
השלישי — ניהול המדיניות. כשהכללים חיים ב-repository ומוחלים ביד, ההקלות מצטברות בקלאסטר אחד ולא מגיעות לאחר: בסביבת הבדיקות המוטציה עבדה, בפרודקשן היא לא קיימת, והוולידציה דוחה את מה שבבדיקות עבר. השליטה על קונפיגורציית הקלאסטר מתפוררת בשקט, בלי שגיאות מפורשות — בהמשך נסביר איך זה נסגר.
מה משתנה אחרי ההטמעה: אפקטים מדידים
Kyverno משתלב ברגע קבלת האובייקט לקלאסטר, ולכן האפקט נמדד במדדי תחזוקה ולא בתחושות. להלן ארבעה גדלים שמשתנים בשבועות הראשונים אחרי המעבר.
שיעור השינויים שעברו בלי תיקון ידני
הדרישה מתוארת פעם אחת: תוויות חובה, מגבלות משאבים, מקורות אימג'ים אסורים. המהנדס לא משווה קונפיגורציות בעין אלא מקבל סירוב עם סיבה ישירות בפלט הפקודה — שיעור התיקונים שמוחזרים למחבר להשלמה יורד מעשרות ליחידות.
זמן בדיקת השינוי
ניתוח הקונפיגורציה מצטמצם משעות לדקות: הסוקר בוחן את המשמעות של השינוי ולא את ההתאמה לתקנון. סטיות טיפוסיות נחתכות אוטומטית, עוד לפני שהן מגיעות לענף הראשי, ולכן הבדיקות מפסיקות להיות צוואר הבקבוק של הריליס.
סוג הכשלים שנעלם
מקור נפרד לתקלות — פער בין סביבות: בסביבת הבדיקות הקפידו על הכלל, בפרודקשן שכחו. המוטציה מביאה את האובייקט לצורה אחידה בזמן היצירה, והדרישות מהסביבות נהיות זהות מעצם הבנייה ולא לפי הסכמה במסמך.
זמן ההתאוששות אחרי קונפיגורציה שגויה
אם שינוי שגוי בכל זאת עבר, היצירה של אובייקטים תלויים והסיבה המפורשת לסירוב מקצרות את הניתוח. זמן ההשבתה נמדד בדקות: החזרה לאחור מתוארת באותה מדיניות כמו האיסור, ולא בתרחיש נפרד.
מצבי החלה של כללים: ביקורת, חסימה, מוטציה
אותו כלל ב-Kyverno מתואר פעם אחת, והמצב קובע מה יקרה כשיש אי-התאמה: רשומה בדוח, סירוב ליצור את האובייקט או תיקון המניפסט תוך כדי. סדר ההטמעה — ביקורת על קלאסטר חי, אחר כך ריצה יבשה על מניפסטים אמיתיים, ורק לאחר מכן חסימה: אחרת הכלל המחמיר הראשון כבר עוצר את הפריסה.
מוטציה ויצירה הן קטגוריה נפרדת: הן לא דוחות את האובייקט אלא מביאות אותו לצורה הרצויה או יוצרות אובייקטים קשורים. מפעילים אותן אחרי שהביקורת הראתה מה בדיוק חסר למשאבים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מצב ביקורת | ריצה ראשונה על קלאסטר חי: לאסוף הפרות בלי לעצור את הפריסה | לא אוסר דבר — הסטיות ממשיכות להיווצר |
| ריצה יבשה | לבדוק כלל חדש על מניפסטים אמיתיים לפני ההפעלה | לא רואה החלטות שתלויות במצב הנוכחי של הקלאסטר |
| מצב חוסם | כשההפרות נותחו ואין התראות שווא | מניפסט לא תקין נופל כולו — הפריסה נעצרת |
| מוטציה של משאבים | השלמה אוטומטית של תוויות, מגבלות וערכי ברירת מחדל בטוחים | משנה את המניפסט המקורי: פער מול ה-repository |
| יצירת אובייקטים | נדרשים אובייקטים נלווים: מכסות, מדיניות רשת, הרשאות | דורש כללי מחיקה — האובייקטים נשארים אחרי הסרת התווית |
בתוך מעבר אחד הכללים מוחלים ברצף: מוטציה, אחר כך בדיקה, אחר כך יצירה. כלל חוסם לכן בודק אובייקט שכבר תוקן.
שלבי ההטמעה: מניתוח הקלאסטר ועד המסירה
סדר העבודה נבנה כך שאף שלב לא מעכב את הפיתוח לפני שנראה את התמונה האמיתית של הקלאסטר. תחילה מיפוי ותכנון הכללים, אחר כך ריצה רכה, ניתוח התראות שווא ורק לאחר מכן חסימה. זה מסיר את הסיכון העיקרי: מדיניות שמופעלת מיד במצב מחמיר עוצרת את הפצת הריליס בגלל מניפסט חריג אחד.
- ביקורת הקלאסטר. ממפים אובייקטים וחריגים: קונטיינרים עם הרשאות-על, כרכי host, אימג'ים בלי תג מקובע, קונטיינרים בלי מגבלות. בנפרד מתעדים מרחבי שמות ועומסי מערכת שאסור לגעת בהם.
- תכנון מערך הכללים. ממיינים את מה שנמצא לפי סוגי הפרות — כלל אחד לכל סוג, עם נוסח סירוב מובן. מתאמים מה עובר לחסימה ומה נשאר כאזהרה.
- פיילוט בסביבת בדיקות. מריצים את כללי Kyverno על העתק של הקלאסטר, מנתחים את הדוחות ומתקנים את הניסוחים עד שהתראות השווא נעלמות.
- הרצה רכה. מפעילים את המערך במצב ביקורת על סביבת העבודה: בודקים כמה אובייקטים מפרים, מי יוצר אותם והאם זה מפריע לפריסה.
- מעבר לחסימה. מעבירים כלל-כלל, החל מאלה שהדוחות שלהם נקיים. עבור עומסים שעברו בירושה — חריגים ממוקדים עם מועד לבדיקה חוזרת.
- קבלת הכללים. מריצים תרחישי עקיפה: החלפת אימג', הרצה כ-root, היעדר מגבלות. בודקים שהכלל פועל ולא שובר ריליסים שגרתיים.
- מסירה לתפעול. מוסרים repository עם המדיניות, תרשים עדיפויות, תקנון חריגים ונוהל עדכון המערך.
מדיניות גישה ומערך התיעוד הנמסר
מדיניות שאיש לא תיאר במילים הופכת אחרי חצי שנה למערך כללים שמפחדים לגעת בו: לא ברור מה בודקת כל הוראה ומה יקרה אם מכבים אותה. לכן יחד עם הקלאסטר המוגדר הלקוח מקבל מערך שבו לכל כלל יש תיאור, ולצוות יש נוהל עבודה מסוכם איתו.
- מרשם כללים. לכל מדיניות מצוין מה היא בודקת, אילו משאבים היא נוגעת בהם, האם היא פועלת במצב חוסם או רק במצב דיווח, ומדוע.
- תפקידים והרשאות. עריכת המדיניות ואישור ההפעלה שלהן מופרדים בין אנשים שונים; ההרשאות ניתנות דרך תפקידים ולא דרך חשבון משותף אחד.
- תרשים ההחלה. המסלול של הכלל מה-repository ועד הקלאסטר: היכן נמצא המקור, איך הוא עובר בדיקה, מתי הוא מתחיל לפעול ואיך חוזרים ממנו לאחור.
- תקנון שינויים. כלל חדש קודם אוסף הפעלות במצב דיווח ורק אחרי ניתוח עובר למצב חוסם — עצירות המוניות של פריסות לא קורות.
- נוהל חריגים. איך מנסחים חריג לפי מרחב שמות או תווית, מי מאשר אותו ומתי הוא מוסר, בלי לדרוש עריכה של הכלל עצמו.
- הוראות למשמרת תורנית. מה עושים אם כלל עצר את הפריסה: איך להבדיל בין התראת שווא להפרה אמיתית, היכן בודקים את הלוג ובאיזה סדר מסירים את החסימה.
- דוחות הפעלה. ייצוא מוגדר של אירועים לפי כללים — רואים אילו בדיקות מפריעות לעבודה לעתים קרובות יותר, ואילו הגיע הזמן להחמיר.
איך בקלאסטר אחד ביטלו את התיקונים הידניים בקונפיגורציות
קלאסטר עם כמה עשרות שירותים ושלוש סביבות — פיתוח, pre-production, פרודקשן. כל עריכה של מניפסט עברה דרך ריוויו ידני: המהנדס התורן פתח diff, השווה מגבלות, תוויות, מדיניות אבטחה ומאגר האימג'ים. פערים בין הסביבות צפו רק אחרי השחרור.
מה היה
לריוויו הגיעו 60-80 עריכות בשבוע, כל אחת ארכה מעשר דקות. לפרודקשן הגיעו כ-10% — השאר הוחזרו להשלמה אחרי build ובדיקות. המחבר לא הבין מה בדיוק הפר: לא היו כללים פורמליים, היו הסכמות.
מה שינו
הכללים הועברו ל-Kyverno. הוולידציה דוחה את המניפסט לפני ההחלה: אין מגבלות משאבים, אין תווית בעלים, תג אימג' צף, כתיבה למרחב שמות זר. המוטציה משלימה בעצמה את השדות החסרים ומביאה את הסביבות לתבנית משותפת, והיצירה יוצרת מכסות וכללי רשת יחד עם האפליקציה.
מה נהיה
הסירוב מגיע בתוך דקה ובציון הכלל שפעל — דחייה מוקדמת במקום ניתוח בדיעבד. הבדיקות הידניות פחתו בסדר גודל, וזמן התגובה לשגיאה הצטמצם משעות לדקה. החזרות בגלל קונפיגורציה אחרי השחרור כמעט נעלמו, והפערים בין הסביבות הפסיקו להיות משימה נפרדת.
מה עושים אם בקלאסטר כבר יש כללים וחריגים משלו?
הכללים לא מבטלים את מה שכבר נעשה — הם מתייצבים לצידו ומחליפים בהדרגה את מה שנצבר. מתחילים ממצב ביקורת: המערך החדש מתעד הפרות אבל לא חוסם פריסה, ומיד רואים היכן הוא סוטה מההקלות שניתנו קודם ואילו עומסי עבודה הוא פוגע בהם ראשונים. למצב חוסם מעבירים כללים אחד-אחד ורק אחרי ניתוח הפערים האלה.
קונפליקט בין כללים נולד לרוב במפגש בין המוטציה לוולידציה. אם כלל קודם משלים תווית או קונטיינר נלווה, הבדיקה רואה אובייקט שכבר שונה ופועלת אחרת מהצפוי. לכן את המצב הרצוי מתארים במוטציה, ואת הדרישות — בוולידציה מעליה, ומחזיקים אותן יחד כדי שסדר ההחלה יהיה צפוי.
הירושה נבנית מלמעלה למטה: דרישות בסיס חיות ברמת הקלאסטר, ותוספות — במרחבי שמות נפרדים. חריג שהוכרז למעלה חל בכל מקום; חריג מלמטה לא אמור להסיר בשקט דרישה מהשכנים, אחרת מרחב שמות אחד מחליש את המדיניות לקלאסטר כולו.
כל חריג ישן מועבר כרשומה נפרדת עם סיבה ומועד בדיקה חוזרת, ולא כעקיפה כללית של הבדיקות. מה שלא מצליחים להסביר במילים נסגר בדרישה — בדרך כלל אלה כללים שנוספו פעם «לזמן מוגבל».
בדיקות מקומיות מפנים אחרונות: כל עוד המערך החדש במצב ביקורת לא יראה התאמה איתן על כל עומסי העבודה, הסקריפטים נשארים כרשת ביטחון. אחר כך מכבים אותם אחד-אחד, ובקלאסטר נשאר מקור דרישות אחד עם סדר החלה מובן.
ספקות טכניים: מגבלות ותאימות
התחביר של כללי Kyverno הוא נדיר בין המקורות לקשיים; השאלות מתחילות בתפעול. מה יקרה לשחרור כשהקונטרולר לא זמין, איך לא לפגוע ברכיבי מערכת ומה לשנות בעדכון גרסאות — בהמשך עונים לספקות שצוות תחזוקת הקלאסטר מעלה לרוב.
מה יקרה אם קונטרולר המדיניות לא זמין?
הקלאסטר פועל לפי מצב הכשל שנבחר: רך מניח לבקשות לעבור בלי בדיקה, מחמיר — דוחה. את המחמיר שמים ממוקד, על כללים קריטיים, עם timeout קצר ותחום בדיקה צר.
האם המדיניות יכולות לעצור שחרור של אפליקציה?
לפני הכפייה מריצים את הכלל במצב ביקורת: הדוחות מראים כמה אובייקטים יפרו אותו, והשחרור לא נחסם. המעבר למצב מחמיר — רק אחרי טיפול בפערים.
איך מחריגים רכיבי מערכת של הקלאסטר?
רשת, אוטוסקיילינג ואחסון מוציאים מתחת לכללים דרך חריגים לפי תוויות של מרחבי שמות. אחרת בדיקה אחת עלולה לעצור את סביבות המערכת לפני סביבות האפליקציה.
אילו מגבלות יש לכללים עצמם?
לא הכול מתבטא באופן דקלרטיבי: תלויות בין משאבים וסדר המוטציות מתוארים במפורש. היצירה יוצרת אובייקטים במרחבי שמות חדשים — על קיימים היא לא חלה.
איך מתבצע עדכון גרסאות?
הכללים קשורים לגרסת ה-API של הקלאסטר. את העדכון בודקים בסביבת הבדיקות על אותו מערך מניפסטים ומעבירים בשלבים, תוך שמירה על תאימות למדיניות הקיימת.
נדבר על המשימה: ממה מתחילה ההגדרה
כדי שניתוח המשימה יארך שיחה קצרה אחת ולא סדרה של הבהרות, כדאי לאסוף מראש כמה נתוני פתיחה. לא נדרש שום דבר אקזוטי — מה שכבר יש לצוות שלכם: גישה לקלאסטר בקריאה, המניפסטים הנוכחיים של המדיניות ותיאור של אילו בדיקות כבר מכוסות בכלים הקיימים ואיפה הן לא פועלות.
אחר כך עוברים על הקלאסטר ובודקים אילו כללי ולידציה, מוטציה ויצירה יניבו אפקט אמיתי ואילו מתנגשים עם עומסי העבודה הקיימים. חוזרים עם הערכת לוחות זמנים ותוכנית עבודה: מה עושים ראשון, אילו מדיניות מפעילים במצב ביקורת ואילו במצב חוסם, ואיך כל שינוי מוחזר לאחור.
מה נדרש מהלקוח כדי להתחיל:
- רשימת הקלאסטרים והסביבות, עם הסדר שבו נוגעים בהם.
- גישת קריאה ל-API server ול-repository עם המניפסטים — אפשר דרך המהנדס שלכם.
- המדיניות הנוכחית: מה הוגדר ידנית, מה דרך קונטרולרי admission, ואילו חריגים כבר הצטברו.
- נקודות הכאב: אילו פריסות נשברו בגלל תגים שגויים, מגבלות או תוויות חסרות.
- דרישות אבטחה וביקורת: אילו בדיקות חייבות לחסום פריסה ואילו מספיק לתעד בלוג.
- איש קשר של מהנדס שיאשר החלטות בנוגע למדיניות ולהרשאות גישה.
- מגבלות על חלונות שינוי — מתי מותר להפעיל מצב חוסם בסביבת העבודה.
מצדנו אנו נותנים תרשים של פריסת המדיניות, קונפיגורציות בחלוקה לפי מרחבי שמות, סדר בדיקה בסביבת הבדיקות ותיאור של נוהל ההחזרה לאחור. אם חלק מנתוני הפתיחה עדיין לא ידוע — זו לא סיבה לדחות: נתחיל מביקורת של המצב הנוכחי ואת החסר נסגור תוך כדי.