Pod IP, ClusterIP או מאזן עומסים פנימי למשתמשי VPN
כתובת Pod IP ניתנת לניתוב דרך ה-VPN עד שה-Pod מוחלף. השוו גישה ישירה ל-Pod, ClusterIP ומאזן פנימי, ומה כל אחד מהם עולה לכם.
עם VPC CNI, Pod יכול להחזיק כתובת מה-VPC, ומשתמש VPN עם המסלול הנכון יכול להגיע אליו ישירות. זה גורם לגישה ישירה ל-Pod להיראות כמו האפשרות הפשוטה ביותר, והיא אכן כזו, עד שה-Pod מוחלף. הכתובת שמשתמש זוכר צריכה להיות שייכת ליישום, ולא לעותק. השוואה בין שלוש נקודות הכניסה מסתכמת בשאלה איזה אובייקט מחזיק בכתובת ומה חייב להמשיך לעבוד כשהעומס עובר.
בחרו קודם לפי מחזור חיים, ואחר כך לפי מה שהרשת צריכה לעשות כדי שנקודת הכניסה תהיה נגישה.
שלוש נקודות כניסה, שלושה מחזורי חיים
כתובת Pod IP שייכת ל-Pod: היא מוקצית איתו ומשוחררת כשמסתיים. ClusterIP שייך ל-Service והוא וירטואלי, ויש לו משמעות רק היכן שקיים ניתוב השירותים באשכול. מאזן עומסים פנימי שייך למשאב ענן שהבקר של האשכול מתכנת עם עורפיים. מודלי בעלות אלה חוזים את התקלה שתקבלו: כתובת מיושנת, שם שאינו נגיש, או קבוצת עורפיים לא מעודכנת.
כתבו את ההשוואה לפני שתבחרו. אחרי שהבעלים והתקלה נקראו בשם, הבחירה בדרך כלל עושה את עצמה.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
גישה ישירה ל-Pod: שימושית, זמנית
גישה ישירה שימושית באמת לבדיקה מבוקרת: מנהל אחד, הפעלה קצרה אחת, פורט אחד מסוים. אבל זה חוזה גרוע למשתמשים, כי הכתובת היא פרט מימוש שמשתנה בכל פריסה. ותיעוד של אחת בוויקי הוא הדרך שבה שירות עובד הופך לשמועה.
היא גם מזמינה כללים רחבים. הרשאה למנהל אחד להגיע ל-Pod אחד אינה הרשאה לכל כתובת בתת-הרשת של הצומת, והשנייה היא מה שנכתב בדרך כלל.
ClusterIP: מוגבל לאשכול לפי התכנון
ClusterIP עובד מפני שמישור הנתונים של האשכול מתכנת עבורו ניתוב בתוך האשכול. ממחשב נייד ב-VPN הכתובת לא אומרת דבר אלא אם משהו חושף אותה בכוונה. שם שמסתיים ב-svc.cluster.local שייך ל-DNS של האשכול, ולכן העתקתו ללקוח עם פותר אחר מייצרת שם שלא קיים ולא שגיאת ניתוב.
ClusterIP נשאר נקודת הכניסה הנכונה לקוראים בתוך האשכול, כולל עומסים אחרים. הוא פשוט אינו מנגנון פרסום למשתמשים מחוץ לתחום הניתוב של האשכול.
מאזן עומסים פנימי: המסלול המפורסם
מאזן עומסים פנימי נותן לכם כתובת פרטית יציבה ושם שהאזור שלכם יכול להצביע עליו, בעוד הבקר שומר על קבוצת העורפיים מעודכנת, כפי שמתאר מדריך איזון העומסים של EKS. זו נקודת הכניסה ששורדת החלפת Pod רגילה בלי שאף אחד יערוך מסמך. היא עולה משאב ענן, תצורת בקר ומסלול מה-VPN, ואלה החלקים שאנשים ממעיטים בערכם.
השתמשו במודל הבקר שהאשכול מריץ בפועל. הערות שנכתבו לאינטגרציה אחת אינן חלות על אחרת.
מי היא כתובת המקור
קבוצות אבטחה רואות את המקור שמגיע לגבול שלהן, וזה יכול להיות הלקוח המחובר או כתובת מתורגמת בהתאם למסלול ה-VPN ואיזון העומסים. בצמתים מבוססי EC2, Pods רגילים של VPC CNI יורשים כברירת מחדל את קבוצות ה-ENI של הצומת, בעוד תצורות נתמכות יכולות לצרף קבוצות ייעודיות ל-Pod. כתבו כללים למסלול המתועד ולא לכתובת מחשב נייד משוערת.
החזיקו את המאזין והאימות של היישום עצמו כבקרות נפרדות. כלל רשת שמתיר את הזרימה אינו החלטת הרשאה ואין להתייחס אליו ככזה.
מה למסור למשתמשים
תנו למשתמשים שם שירות, לא כתובת. פרסמו את השם באזור הפרטי, הפנו אותו לנקודת הכניסה הפנימית, ואז בדקו על ידי החלפת Pod עורפי בזמן שהלקוח מחזיק את אותו שם פתוח. התרגיל הזה בודק את התכונה שחשובה: להגיע לאותו יישום אחרי פריסה שגרתית.
החזיקו את הגישה הישירה ל-Pod כחריג תפעולי מתועד עם היקף משלו, הרחק מהוראות למשתמשים.