VPN בפוד ב-Kubernetes מול שער יציאה: למי שייכת המנהרה?
פוד הוא מרחב השמות של הרשת של עצמו, ולכן הבחירה האמיתית היא איזו שכבה מחזיקה במנהרה: זהות לכל עומס עבודה או יציאה מונחית CNI עם מקור משותף אחד.
אתם פורסים פוד בשם vpn-gateway, מפנים לקוח בדיקה לכתובת שלו ורואים את החבילות נעלמות. שום דבר במניפסט אינו שגוי ול-kubelet אין תלונה. הסיבה מבנית ולא הגדרתית: Kubernetes נותן לכל פוד מרחב שמות רשת משלו, ולכן שם, תווית או מרחב שמות API משותף אינם משנים דבר לגבי היכן הולכות החבילות. לכן ההחלטה כיצד תעבורת VPN יוצאת מהאשכול מתחילה בשאלה של בעלות, לא בשאלה של אימג’י מכולות.
שני מנגנונים מכסים את רוב הפריסות האמיתיות, והם אינם ניתנים להחלפה. האחד מכניס את המנהרה למרחב השמות של הרשת של עומס העבודה עצמו. האחר מבקש מה-CNI לנתב תעבורה נבחרת דרך צומת שער ייעודי. הם נכשלים אחרת, מתרחבים אחרת ומדווחים לצוותים שונים, ולכן שאלת המכולה מייצרת בדרך כלל ויכוחים שלעולם אינם נפתרים.
גבול של פוד הוא מרחב שמות, לא מארח קפיצה
מרחב שמות רשת של Linux מחזיק בממשקים, בכתובות, בנתיבים ובכללי חומת האש שלו, וכל פוד מקבל אחד. מכולות בתוך אותו פוד מצטרפות אליו, וזו בדיוק הסיבה שמכולת עזר יכולה לשכתב נתיבים שהאפליקציה עוקבת אחריהם בהמשך. לפוד שכן יש מחסנית שנראית זהה אך נפרדת לחלוטין. אין טבלה משותפת שפוד שער יוכל לרשת, ואין העברה מרומזת של תעבורה ממרחב שמות אחד לאחר.
זו גם הסיבה שתבנית פוד השער עובדת רק כאשר משהו במעלה הזרם באמת שולח אליו חבילות: Service, נתיב סטטי על הצומת או מדיניות ניתוב ב-CNI. כתובת לבדה אינה מושכת דבר.
מה מנהרה לכל פוד קונה, ומה היא עולה
מנהרה שרצה במרחב השמות של עומס העבודה מעניקה לאותו עומס זהות לקוח משלו, ששירותי גישה מרחוק רבים דורשים אותה לפני שהם מאשרים או מחשבים הפעלה. גם רדיוס הפגיעה נשאר מקומי: מנהרה שבורה מפילה Deployment אחד במקום הנתיב המשותף שבו משתמש הכול. איך היא רצה תלוי ביישום, וכאן אנשים מנחשים לא נכון.
התקנה שזקוקה רק למצב ליבה יכולה להסתיים במכולת init ולצאת. דמון במרחב משתמש שחייב להישאר חי לכל אורך חיי הפוד זקוק לצורת מכולת init ניתנת לאתחול שהוצגה כ-sidecar מקורי ב-Kubernetes 1.29, וההבחנה הזו מגיעה מהיישום של המנהרה ולא מטעם. המחיר של המודל הזה הוא כפילות: כל רפליקה מאמתת, מקבלת כתובת מנהרה משל עצמה וצורכת מקום הפעלה מרוחק, ולכן אירוע סקיילינג אוטומטי הופך לאירוע קיבולת בצד השני של הקישור. העתקת אישור אחד לכל הרפליקות אינה מסירה את המחיר הזה, היא מסירה את שובל הביקורת. הרשאות ראויות לאותה בחינה, כי מנהרה שרוצה NET_ADMIN במרחב השמות של עצמה אינה צריכה לרשת את הסמכות על כל המארח מדוגמה עם privileged: true.
כשה-CNI מחזיק ביציאה
אם ה-CNI תומך בכך, שער יציאה בוחר תעבורה לפי עומס עבודה וטווח יעד, ואז שולח אותה דרך צמתים נבחרים תחת כתובת מקור אחת צפויה. הגרסה של Cilium היא ההפניה המקובלת, והתיעוד שלה אומר במפורש שהתכונה דורשת תצורת Cilium מסוימת בתוספת צמתי שער המסופקים עם הממשקים והכתובות הנכונים. הוא גם מציין תקופה ראשונית לאחר יצירת הפוד שבה הניתוב עדיין אינו נאכף, וזה קלט תכנון ולא הערת שוליים.
קראו את העיכוב הזה מול ההבטחה שלכם. אם הכלל הוא ששום תעבורה אינה רשאית לצאת בנתיב אחר, פוד חדש שמשדר במהלך הפער כבר הפר אותו, ולכן רצף האתחול צריך תשובה משל עצמו: לעכב את האפליקציה עד שהמדיניות חלה, או לקבל את החלון ולתעד אותו.
השאירו את הטענה צרה. שער יציאה בוחר ומתרגם נתיב. הוא אינו מסיים VPN, והוא אינו הופך את האשכול ללקוח של הרשת המרוחקת שלכם בלי חיבור נתמך מאחוריו.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
התרגום משנה בשקט את מה שהצד המרוחק רואה
לאחר שהשער משכתב את המקור, הכתובות לכל פוד נעלמות, ולכן רשימת היתר המבוססת על זהות הופכת לרשימה המבוססת על כתובת משותפת אחת. זהו סחר חליפין ולא פגם: פחות כללים לתחזק, ייחוס גס יותר כשמשהו מתנהג רע.
אימות ברמת האפליקציה ותיעוד בקשות חייבים לשאת את מה שהרשת אינה מדווחת יותר. התייחסו לקיבולת השער ולהחלפתו כתשתית משותפת, כי אתחול צומת אחת מקטע כעת כל עומס עבודה שמאחוריו, ובדקו את נתיב החזרה מוקדם: הצד המרוחק חייב לדעת איך להגיע לכתובת המתורגמת, בדרך כלל דרך נתיב או NAT שאדם, ולא מניפסט, חייב להחזיק. גם תכנון כתובות שייך לכאן, כי טווחי אשכול ומרוחקים חופפים שוברים כל אחד מהמודלים ואימוץ IPv6 אינו תירוץ לתוכנית סותרת.
החליטו לפי בעלות, ואז בחנו את הכשל שהבטחתם
בחרו במנהרה לכל פוד כאשר השירות המרוחק מאמת עומסי עבודה בודדים, כאשר רק כמה Deployment זקוקים לקישור, וכאשר כשל צריך להישאר מקומי. בחרו בשער כאשר צוות רשת כבר מחזיק בנתיב, כאשר עומסי עבודה רבים חולקים יעד אחד, וכאשר כתובת מקור יציבה היא כל מטרת התרגיל.
כך או אחרת, אמתו את התכונה שמכרתם ולא את מצב היציבות. צרו פוד, תנו לו לשדר מיד והתבוננו בשניות הראשונות אם ההבטחה הייתה ששום דבר לא נמלט מהמנהרה. הסקילו לחמש רפליקות וספרו את ההפעלות שהצד המרוחק מדווח עליהן אם ההבטחה הייתה זהות לכל עומס עבודה. שתי הבדיקות האלה חושפות את גבולות המנגנון הרבה יותר מהר מסקירה של המניפסט, והן אומרות לכם איזה צוות מחזיק בתקרית הבאה.