הגדרת גילוי שירותים בקוברנטיס: CoreDNS ו-Headless Services

Service Discovery ב-Kubernetes: היכן נקרעת הקישוריות

הפודים רצים, בדיקות ה-readiness ירוקות, אבל השירות לא מתחבר: משתתף אחד מקבל שגיאת פתרון שם, אחר דופק בכתובת שכבר אינה קיימת. Service Discovery ב-Kubernetes נשבר לא באופן מלא, אלא חלקית — חלק מהקריאות עוברות, חלק תלויות עד ל-timeout.

מחלקת הכשלים הראשונה — כשל בשכבת השמות. CoreDNS לא עונה כשהוא נתקל במגבלות משאבים, מאבד חיבור ל-API server או נשאר בעותק יחיד לאחר פינוי פודים. בלוגים של האפליקציה זה נראה כזינוק בשגיאות פתרון שמות, אף שהשירות עצמו חי ועונה בכתובת ישירה.

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

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

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

מה נותנת ההגדרה: מהירות שחרור וכשלים שנמנעו

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

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

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

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

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

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

מצבי גילוי: רשומות DNS, מצב headless, רישומים חיצוניים

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

במצב headless, CoreDNS מחזיר לבקשת dns את הרשימה המלאה של הכתובות, והאיזון נעשה על ידי הלקוח. זהו חילוף מודע: הפלטפורמה מפסיקה להיות מתווכת ונקודת כשל, אבל הלקוח צריך לדעת לחזור על הבקשה כשההרכב משתנה.

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

שלבי העבודה: אבחון, סכימה, הגדרה, בדיקה, מסירה

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

1. אבחון הקלאסטר — אוספים מפת שירותים ומרחבי שמות, בודקים כיצד מתבצע כיום פתרון השמות, היכן נותרו רשומות ידניות ואילו מדיניות רשת חותכות תעבורת DNS. בנפרד מתעדים נקודות כשל: עותק יחיד של CoreDNS, היעדר מטמון, timeouts קשיחים בלקוחות.
2. סכימת גילוי — מחליטים היכן די בשירות רגיל והיכן נדרש headless לגישה ישירה לפודים. מגדירים אזורים, כללי העברה ומה עובר ל-DNS חיצוני.
3. הגדרת CoreDNS — מתקנים את התצורה לפי הסכימה הזו: אזורים, העברה, מטמון, מגבלות, בדיקות מוכנות. העותקים מפוזרים על פני צמתים ואזורי זמינות, כדי שכשל של אחד לא יפיל את פתרון השמות.
4. בדיקת עמידות בכשלים — מכבים עותק ואת הצומת שאיתו, בודקים אם ה-resolve נשמר וכיצד הלקוחות עוברים השהיית תשובה. בנפרד מריצים שירותי headless ועדכון רשימת ה-endpoints.
5. נראות — מוציאים מטריקות של בקשות, כשלים וזמן תגובה, קובעים ספים לתורנות, כדי שהדעיכה תהיה גלויה לפני התלונות.
6. מסירה לתפעול — סכימה, נהלים וסדר פעולות טיפוסיות: כיצד לחבר שירות חדש, כיצד להחזיר שינוי לאחור, מה לבדוק ראשון בעת תקלה.

מארז האספקה: תצורות, סכימות, נהלים

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

• תצורות עובדות: מניפסטים ו-ConfigMap עבור CoreDNS, שירותי headless ואובייקטים קשורים — במערכת בקרת הגרסאות שלכם, עם היסטוריית שינויים.
• סכימת טופולוגיית הגילוי: כיצד השירותים מוצאים זה את זה, אילו רשומות נוצרות עבור StatefulSet, כיצד נפתרים שמות בתוך הקלאסטר ומחוצה לו.
• מדיניות גישה: תפקידי RBAC, NetworkPolicy ומגבלות על עריכת אזור — מי ומאילו מרחבי שמות יכול לקרוא ולשנות רשומות.
• דיאגרמת עמידות בכשלים: מספר עותקים, פיזור על פני צמתים, התנהגות בעת אובדן צומת או אזור.
• נוהל תפעול: פעולות טיפוסיות — חיבור שירות, החלפת אזור, רוטציית תעודות — עם נקודות בדיקה וסדר החזרה לאחור.
• סט בדיקות: מטריקות וסקריפטים לבקרת פתרון שמות, השהיית תגובות ושיעור שגיאות, עם ספים לתורנות.
• תיעוד: תיאור הסכימה, ההחלטות שהתקבלו והמגבלות הידועות — כדי שמהנדס חדש ייכנס לקו בלי הסברים בעל פה.

קייס: כיצד הסרנו עריכות ידניות של כתובות לאחר ריליס

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

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

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

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

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

מה לעשות אם ב-Kubernetes כבר פרוס CoreDNS?

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

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

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

לאחר מכן מתקנים עותק ב-ConfigMap, בלי להחיל אותו על קו הייצור, ובודקים ממרחב שמות בדיקה: resolve של שמות פנימיים וחיצוניים, התנהגות של search-domains והפרמטר ndots.

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

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

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

ספקות טכניים: מטמון, timeouts, מגבלות של מצבים

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

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

מה יקרה אם צומת עם עותקי DNS ייפול?

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

headless מחזיר רשימת כתובות בלי איזון — מהי המגבלה?

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

נדון במשימה שלכם: ממה נתחיל

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

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

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

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