הגדרת Linkerd Service Mesh ב-Kubernetes: mTLS, קנרית, נראות

מדוע שירותים מאבדים בקשות ללא Linkerd service mesh

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

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

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

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

השפעות מדידות: זמנים, כשלים, יכולת תצפית

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

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

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

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

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

מצבי עבודה של רשת השירותים והמגבלות שלהם

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

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

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

שלבי הטמעה: מביקורת תעבורה ועד מסירה

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

1. ביקורת תעבורה. מסירים מפה של קשרים: מי מתקשר עם מי, באילו פורטים, היכן חיבורים עוקפים את הקלאסטר. הבסיס — מטריקות רשת, תיאורי שירותים ולוגים של פרוקסי.
2. סכמת ניתוב. מתעדים את הכתובות בתוך service mesh ואת הכללים לתעבורה חיצונית: מה נגיש מבחוץ, איך מתחלקות הבקשות בין גרסאות. את הסכמה מתאמים לפני שינויים בקלאסטר.
3. הפעלת אימות הדדי. תחילה מצב תצפית: חיבורים נבדקים אך לא נחסמים — רואים מי עדיין לא יודע להציג את עצמו. אחר כך מצב מחמיר, לפי שירותים, החל מהלא-קריטיים.
4. בדיקה תחת עומס. מסירים השהיות, שיעור תשובות מוצלחות והתנהגות בעת כשל של מופע אחד, תוך השוואה למדידות לפני ההטמעה. בנפרד מריצים ניתוק חיבור ועדכון גרסה.
5. יכולת תצפית ותקנונים. מגדירים דשבורדים לפי קשרים בין שירותים, התראות על עלייה בשגיאות ועל תוקף תעודות. מתעדים כללים להוספת שירות ולהחזרת שינויים.
6. מסירת הפתרון לצוות. מוסרים קונפיגורציות במאגר, סכמת ניתוב ותקנון לחיבור שירות חדש. ההדרכה נעשית על סטנד חי כדי שהמהנדסים יבצעו חיבורים בעצמם.

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

חבילת מסירה: קונפיגורציות, סכמות ניתוב, תקנונים

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

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

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

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

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

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

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

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

מטריקות לפני ואחרי

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

במה Linkerd שונה מהגדרה ידנית של הצפנה

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

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

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

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

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

שאלות שנשאלות לפני הטמעת הרשת

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

בכמה תגדל ההשהיה?

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

כמה עבודה תיפול על הצוות שלנו?

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

האם אפשר להפעיל בהדרגה?

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

נדון במשימה שלכם ונחזור עם תוכנית הטמעה

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

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

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

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