Pod, צומת או אשכול: מה sidecar של VPN באמת מנתב מחדש

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

מרחב שמות משותף, השלכות משותפות

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

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

לאן ה-sidecar לא מגיע

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

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

תוכנית מסלולים: טווחי Pod, שירות, צומת ו-VPN

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

DNS הוא חלק מהתוכנית ולא דאגה נפרדת. sidecar אשר כותב מחדש את תצורת ה-resolver יכול לשבור גילוי שירותים בתוך האשכול בזמן ששאילתות חיצוניות עובדות באופן מושלם.

הפעלה וכשל הם מצבים מפורשים

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

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

צמדו את הסדר לבדיקת כשל. הרגו את ה-sidecar ואשרו שהיישום מאבד את היציאה המיועדת שלו במקום לסגת בשקט.

יכולות, מדיניות ובדיקות מתוך מכולת היישום

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

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

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