מדוע External DNS ב-Kubernetes מפגר אחרי שינויים באשכול
יצרתם מחדש את השירות — ה-Pods עלו, הבדיקות עוברות, אבל התעבורה לא זורמת. הרשומה באזור עדיין מצביעה על כתובת ה-load balancer הקודמת, שכבר אינה קיימת: הלקוח מקבל timeout, למרות שמצד האשכול הכול ירוק.
וכל עוד לא פג ה-TTL של הרשומה, שרתי ה-cache ממשיכים להחזיר את הכתובת הישנה — התקלה נמשכת יותר מהריליס עצמו.
הסיבה היא בפער בין מחזור החיים של אובייקטי האשכול לבין תוכן האזור. השירות חי דקות, הרשומה — עד העריכה הידנית הראשונה, ולכן הפער בין רשומות לשירותים מצטבר עם כל פריסה.
רשומות מיושנות אינן נמחקות מעצמן לאחר יצירה מחדש: נשאר זבל שמתורגם ומפנה חלק מהבקשות לשום מקום, וחלק — למתאר הקודם. האבחון הופך לקשה יותר: מבחוץ הדומיין עונה, בתוך האשכול הכול עובד, וביניהם — אי-התאמה.
מכאן מתחילות עריכות ידניות של אזורים. התורן משווה את רשימת השירותים לתוכן האזור, מנקה את המיותר, מוסיף את החדש — בלילה ותחת לחץ, לפי נוהל שאיש לא בדק את שלמותו. אין בדיקה הפוכה: איש לא מאשר שלא נותרו באזור מצביעים לכתובות שאינן קיימות.
ניהול DNS אוטומטי מסיר בדיוק את העבודה הזו — External DNS מקשר את אובייקטי האשכול ישירות לאזור; נבחן כיצד זה בנוי ומה הוא נותן.
מה משתנה בתפעול: אפקטים מדידים של האוטומציה
בקר External DNS מתחבר לאשכול ופועל כלולאת סנכרון: הוא קורא שירותים ונקודות כניסה עם סימון של שם חיצוני ומביא את הרשומות באזור למצב הזה. מקור האמת נשאר אחד — המניפסט, ולא הפאנל של הרשם, ולכן אין צורך לשכפל שינויים ביד. מכאן האפקט מתפרק לארבעה כיוונים מדידים.
מהירות הופעת הרשומות מפסיקה להיות תלויה באדם: השם מתפרסם בתוך עשרות שניות לאחר החלת המניפסט, ולא בחלון העריכות הידניות הבא, וזמן החיים המקוצר של הרשומה מאפשר להסיר במהירות תשובה מיושנת מה-cache של ה-resolvers.
שיעור הפעולות הידניות באזור יורד למקרים בודדים — בדרך כלל אלה האצלת דומיין ורשומות עבור משאבים מחוץ לאשכול, שמוציאים במודע מתחת לאוטומציה.
הרווח העיקרי — סוג תקלות שחוסל בגלל טעות אנוש: שגיאת כתיב בשם, רשומה שנשכחה לאחר מחיקת סביבה, קונפליקט בין שני בעלים על אותו שם, אי-התאמה בין מה שבאמת עובד באשכול לבין מה שמפורסם באזור.
אי-התאמות כאלה כמעט ואינן נראות בניטור של האפליקציה — הן צפות כ«השירות חי, אבל לא נגיש מבחוץ», והחיפוש סוטה מהסיבה האמיתית.
זמן השחזור של השירות מתקצר: ביצירה מחדש או במעבר העומס מקבל נקודת כניסה חדשה, והרשומה מתעדכנת בלי תורן עם גישה לפאנל הרשם. הפעולה ההפוכה גם היא אוטומטית — מחיקת הסביבה משחררת שמות, ובאזור לא מצטברים מצביעים מתים שנאלצים אחר כך לנקות ביד.
אפשרויות סנכרון DNS: מעריכות ידניות ועד אוטומציה מלאה
ניתן לסנכרן את האזור עם האשכול בארבע דרכים, והבחירה ביניהן היא בחירה בין מהירות התגובה לשינויים לבין צפיות תוכן האזור. External DNS קורא את תיאורי אובייקטי האשכול ויוצר או מעדכן רשומות, אבל מצבי העבודה והמדיניות שלו קובעים מה מותר לו לשנות ולמחוק.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ניהול אזורים ידני | מערך שירותים יציב, ריליסים נדירים | העריכות מפגרות אחרי הפריסה, טעויות ברשומות מתגלות כבר בפרודקשן, הכול נשען על אדם אחד |
| משימות לפי לוח זמנים | שירותים רבים, החלפת כתובות פעם ביום | הרשומה מופיעה באיחור, הרצות במקביל מתנגשות, אין סנכרון מול המצב בפועל |
| אוטומציה לפי תיאור השירותים | סביבות דינמיות, סקיילינג תכוף | נדרשות הרשאות כתיבה לאזור, נדרשת מדיניות מחיקה מפורשת ותוויות על האובייקטים |
| סכימת ניהול היברידית | רשומות קריטיות צריכות להישאר אצל המהנדס | כללי התיחום מורכבים יותר, נדרש רשימת אזורים ורשומות שהאוטומציה לא נוגעת בהם |
בפועל לרוב מגיעים לסכימה היברידית: שירותי הפיתוח מנוהלים אוטומטית, ורשומות השורש והדואר נשארות בידי המהנדס, כי טעות בהן מפילה הכול בבת אחת. הגבולות נקבעים ברשימה מפורשת של אזורים שהאוטומציה לא נוגעת בהם, — ואז פריסת שירות חדש אינה דורשת מעורבות אדם, והאזור נשאר במצב צפוי.
שלבי ההטמעה באשכול Kubernetes: מהאודיט ועד למסירה
את סדר העבודה בונים כך שהאוטומציה של DNS תקבל בדיוק את ההרשאות הנדרשות לפרסום רשומות, ולא תוכל לפגוע באזורים שחיים מחוץ לאשכול. כל שלב מסתיים בארטיפקט שנבדק לפני המעבר לשלב הבא.
- אודיט של אזורים והרשאות. אוספים את האזורים שהאשכול משרת, בודקים אילו רשומות נוצרו בהם ביד ומי אחראי עליהן. עבור ספק הענן פותחים חשבון נפרד עם תפקיד מוגבל: כתיבה מותרת רק באזורים שהוקצו, השאר — קריאה בלבד.
- סכימת התאמה בין שירותים לרשומות. קובעים איזה שם מקבל כל שירות — לפי annotation, לפי תווית או לפי תבנית של בעל הצוות. כאן גם מפרידים קונפליקטים עם רשומות קיימות ומסכמים מי הבעלים של המחיקה.
- הגדרה. מגדירים מקורות שמות, סינון לפי דומיין, מצב סנכרון ותדירות סנכרון. מוסיפים רשומת סמן שירותית: לפיה הבקר מבין שהרשומה נוצרה על ידו ולא דורס רשומה של אחר.
- בדיקה בסביבת בדיקות. על עותק של האזור מריצים תרחישים: פרסום שירות חדש, שינוי שם, מחיקה, קונפליקט שמות, אי-זמינות של הספק. בנפרד בודקים מה קורה לרשומות בעת rollback של הריליס.
- מסירה לתפעול. מוסרים נוהל, הרשאות, מטריקות וסדר פעולות בעת אי-התאמה — מה מתוקן אוטומטית ואיפה נדרש אדם.
קונפיגורציות, סכימות ונהלים בערכת המסירה
ערכת המסירה היא לא ארכיון של מניפסטים, אלא סט ארטיפקטים שלפיהם הצוות שלכם מוסיף אזורים, מבטל הרשאות ומטפל בתקלות בעצמו בלי לפנות אלינו. הכול מאוכסן בריפו שלכם עם היסטוריית שינויים, ואת התרחישים מריצים בסביבת הבדיקות יחד עם משמרת התורנים.
- קונפיגורציות עבודה — מניפסטים של בקר External DNS עם הערכים בפועל: מקורות רשומות, סינון לפי אזורים ודומיינים, תדירות סנכרון, מצב עריכת רשומות.
- מפת אזורים — מה הואצל, היכן ממוקם ה-DNS הסמכותי, אילו רשומות מנוהלות אוטומטית, אילו נוצרו ביד ואסור לגעת בהן, והיכן עוברים גבולות האחריות.
- מדיניות בעלות על רשומות — הבקר עורך רק את הרשומות שלו: תווית בעלים, רישום נפרד, חלוקת אזורים בין צוותים.
- מדיניות גישה — חשבון שירות עבור הבקר, הרשאות רק לאזורים הנדרשים, קריאה וכתיבה מופרדות, מפתחות ב-Secrets עם נוהל רוטציה.
- נוהל תגובה — מה לבדוק בעת אי-סנכרון, היעלמות עדכונים וכשל בגישה לספק; כיצד לחזור למצב הקודם ולמי להסלים.
- הוראות לתורנים — כיצד לראות את תוכנית השינויים בלי להחיל אותה, לוודא שהרשומה מנוהלת אוטומטית, ומה לבדוק בלוגים בעת קונפליקט.
- חיבור אזור חדש — סדר השלבים: האצלה, הרשאות, סינון, הרצת בדיקה, הפעלת עריכות במתאר הפרודקשן.
- Observability — מטריקות של הבקר, התראות על שגיאות אימות ועיכוב בסנכרון, פאנל עבור משמרת התורנים.
את התיעוד כותבים עבור המתאר שלכם, ולא עבור סביבה טיפוסית: שמות האזורים, החשבונות וספי ההתראות בו כבר שלכם, ולכן המסירה לא הופכת לתכנון מחדש.
מקרה בוחן: מעריכות ידניות של רשומות לסנכרון אוטומטי
צוות מוצר החזיק 40+ שירותים באשכול, ואת האזורים בפאנל הרשם ניהל ביד: רשומות A, CNAME ו-TXT נוצרו בטיקטים ונערכו בידי מהנדס תורן. הוצאת שירות, החלפת load balancer או מעבר node הפכו לשרשרת אישורים — העריכה הגיעה לאזור הפרודקשן תוך 30-40 דקות.
ברבעון הצטברו 11 אירועים עם רשומות: רשומה שנשכחה בעת הוצאת שירות, מצביע ל-node שהוסר, כפילויות לאחר מיזוג ידני של אזורים. סך זמן ההשבתה בגלל ניתוב שגוי — כ-9 שעות.
הטמיעו External DNS: מקור האמת הפך ל-annotations של שירותים ואובייקטי Ingress, והגישה ל-API של הרשם ניתנה לחשבון שירות נפרד עם הרשאות רק לאזורים הנדרשים.
בסביבת הבדיקות הפעילו תחילה מצב תצוגה מקדימה — השירות הציג את תוכנית השינויים ולא החיל אותה; סנכרון מול הרשומות בפועל חשף 14 אי-התאמות שנותרו מהתקופה הידנית, והן נוקו לפני ההפעלה באזורי הפרודקשן. אזורי הפיתוח, ה-pre-production והפרודקשן הופרדו לשמות נפרדים, וה-TTL נשמר קצר.
כעת המסלול משתנה יחד עם הפריסה: המהנדס עורך את המניפסט, הרשומה מתעדכנת באותו מחזור, החלון — דקות. ה-rollback הוא החזרת המניפסט הקודם, ולא חיפוש ידני של הכתובת הישנה. ברבעון הבא מספר האירועים עם רשומות ירד מ-11 ל-1, וגם הוא הגיע מצד הרשם, ולא מהאזורים שלנו.
זמני ההשבתה בגלל ניתוב שגוי הצטמצמו מ-9 שעות לחצי שעה, ומצביעים ל-nodes שהוצאו נעלמים יחד עם האובייקטים — רישום האזורים הפסיק לגדול.
מה עושים אם האשכול כבר פרוס והרשומות מנוהלות ביד?
האשכול כבר עובד, והרשומות באזורים נוצרו ביד — המעבר לאוטומציה אינו דורש חלון תחזוקה. מתחילים במיפוי מלאי: מייצאים את הרשומות, מתאימים אותן לאובייקטי האשכול, מסמנים מה נוצר ביד, מה בידי ה-load balancer, מהם ה-TTL ומי בעל הדומיין. בלי המפה הזו, כבר ההרצה הראשונה של הסנכרון תמחק את מה שהוגדר ביד במשך שנים.
מכאן External DNS מופעל במצב צפייה: הרשאות לאזור ניתנות לקריאה בלבד, וההחלטות נבדקות מול המצב בפועל בלי שינויים. העיקר הוא תווית הבעלות: רשומה מנוהלת מקבלת רשומת TXT שירותית עם מזהה הבעלים, והשירות רואה כשלו רק את אלה שבהן התווית תואמת.
רשומות זרות נשארות ללא פגע: מדיניות upsert-only (עדכון והוספה בלי מחיקה) אוסרת מחיקה, והסינון לפי דומיינים מגביל את האחריות לתת-דומיינים שכבר נבדקו.
המעבר מתבצע בשלבים — תחילה המתאר הלא-פרודקשני, ואחר כך אזור פרודקשן אחד בכל פעם עם הפסקה לסנכרון. לפני המעבר מורידים מראש את ה-TTL של רשומות מפתח, ולכן ה-rollback מחזיר את התעבורה תוך דקות. ה-rollback בכלל זול: הסנכרון נכבה, הרשומות באזור נשארות פעילות, כי לא מחקנו אף אחת מהן.
בסופו של דבר השירותים לא מושבתים, הרשומות הקיימות נשמרות, והעריכה הידנית של האזור הופכת לחריג — רק למה שלא מנוהל בידי האשכול.
ספקות טכניים: מגבלות, עמידות בתקלות, הרשאות
לעיתים קרובות תופסים את ExternalDNS כדרך לחלק לצוותים גישה לניהול אזור DNS. בפועל הבקר רואה רק את אובייקטי האשכול שהותרו לו ועורך את האזור בגבולות סינון הדומיין שהוקצה — כל השאר מחוץ לאחריותו.
להלן הספקות שנשמעים לרוב בקבלה: התנהגות בעת תקלות אצל הספק, הגנה מפני מחיקת רשומות זרות, חלוקת הרשאות בין צוותים וגבולות הגישה עצמה.
מה יקרה אם ספק ה-DNS אינו זמין או מחזיר שגיאות?
הבקר חוזר על הבקשות בהשהיה גדלה ולא נוגע ברשומות שלא הצליח לאשר: באזור נשאר המצב האחרון שהוחל בהצלחה, והשירותים ממשיכים להיות מתורגמים לפיו. התראות מגדירים על משך סדרת השגיאות ועל אי-ההתאמה בין האשכול לאזור — את התקלה רואים לפני הריליס הבא, ולא אחרי תלונות משתמשים.
כיצד הבקר יודע אילו רשומות שלו, והאם לא ימחק יותר מדי?
כל רשומה שנוצרת מלווה ברשומת TXT שירותית עם מזהה הבעלים. רק מה שמסומן במזהה הזה משתנה ונמחק, ולכן רשומות שנוצרו ביד נשארות ללא פגע. מצב upsert-only אוסר מחיקה לחלוטין, וסינון הדומיין מגביל את העבודה לאזורים מוגדרים.
כיצד מחלקים הרשאות בין צוותים?
מפרידים מקורות: צוות אחד מפרסם שירותים רק במרחב השמות שלו, אחר — בתת-האזור שלו. הרשאות לאובייקטי האשכול ניתנות בתפקידים, הרשאות לאזור — בחשבון נפרד של הספק עם גישה לאזור אחד. טעות במניפסט לא מוציאה את הצוות מחוץ להיקף.
מהן המגבלות של הגישה?
האוטומציה מכסה רשומות שנגזרות מאובייקטי האשכול. רשומות סטטיות, מסלולי דואר ואיזון גיאוגרפי נשארים בידי מנהל ה-DNS: אם יש רשומות רבות כאלה, נאוטמט רק את החלק השירותי של האזור.
מה להכין לדיון וכיצד נתחיל לעבוד
הערכת ניהול אוטומטי של רשומות DNS נכנסת לשיחה אחת, אם יש בכניסה מלאי של אזורים וגבולות גישה ברורים. להלן נתוני הפתיחה שמסירים את רוב אי-הוודאות: חלק נסגר ישירות בהתכתבות, והשאר — בגישה לסביבת בדיקות.
- רשימת דומיינים ותת-דומיינים שאמורים להיות מנוהלים מהאשכול, והיכן מסתיים הניהול הידני.
- בעל האזור וטוקן גישה ל-DNS עם הרשאות רק לאזור הנדרש, ולא לחשבון כולו.
- רשימת שירותים ונקודות כניסה שזקוקים לרשומות: חיצוניות בלבד או גם פנימיות.
- מצב סנכרון: רשומה לכל אובייקט או רק למסומנים, ומה עושים עם רשומות קיימות.
- מספר הסביבות וכיצד מחולקים האזורים ביניהן.
- חלון השינויים וכלל ה-rollback: מה קורה לרשומה בעת מחיקת שירות.
מכאן הסדר פשוט: שיחה קצרה על נתוני הפתיחה, מיפוי מלאי של אזורים והרשאות, פיילוט על דומיין בדיקה, פריסה לפי סביבות ומסירת נוהל התפעול. הפיילוט נמשך כמה ימים — בו בודקים יצירה, עדכון ומחיקה של רשומות, ובנפרד את ההתנהגות ב-rollback.
פריסה מלאה לפי סביבות — בדרך כלל שבוע עד שבועיים בהתחשב בחלון השינויים. בסופו של דבר נשארת לכם סכימה משועתקת וסדר פעולות ברור, אם תזדקקו להחזיר את הניהול הידני.