אתה עלול להיתקל בבעיה בעת הגדרת אשכול Kubernetes כאשר אתה יודע רק כיצד להשתמש ב-NodePort כדי להפוך את שירות Kubernetes שלך לנגיש דרך האינטרנט. בעת שימוש בסוג שירות NodePort, יוקצה מספר יציאה גבוה ועליך לאפשר חיבורים ליציאות אלו בכלל חומת האש שלך. זה מזיק לתשתית שלך במיוחד אם השרת נגיש דרך האינטרנט הפתוח. אתה יכול להקצות בלוק של כתובות IP מחוץ לאשכול כמנהל אשכול שיכול להעביר תעבורה לשירותים שם. זה בדיוק מה שאנחנו הולכים לדבר עליו במאמר זה: למצוא את כל המידע הקריטי על איך להגדיר כתובות IP חיצוניות של מניעת שירות ב-Kubernetes.
מהו שירות IP חיצוני?
אחת מנקודות הקצה של השירות תקבל תעבורה שנכנסת לאשכול באמצעות ה-IP החיצוני (כ-IP היעד) ויציאת השירות. Kubernetes אינה אחראית לניהול IP חיצוני.
לוודא באיזה IP נעשה שימוש כדי לגשת לאשכול Kubernetes הוא חיוני במצב זה. באמצעות סוג שירות ה-IP החיצוני, אנו עשויים לאגד את השירות לכתובת ה-IP המשמשת לגישה לאשכול.
העובדה שרשת Kubernetes מקיימת אינטראקציה עם רשת Overlay חשובה להבנת המצב הזה. זה מרמז שאתה יכול לגשת כמעט לכל צומת באשכול ברגע שתגיע לכל אחד מהצמתים (מאסטר או צומת עובד).
הרשת מוצגת כך:
שני צמתים 1 ו-2 בתרשים חולקים כתובת IP אחת. הפוד האמיתי חי ב-Node 1 אבל כתובת ה-IP 1.2.3.6 קשורה לשירות Nginx ב-Node 1. כתובת ה-IP של Node 1, 1.2.3.4, קשורה לשירות httpd, וה-Pod בפועל של Node 2 נמצא שם.
זה מתאפשר בזכות היסודות של רשת Overlay. כאשר אנו מסלסלים את כתובת ה-IP 1.2.3.4, שירות httpd אמור להגיב; כאשר אנו מסללים את 1.2.3.5, שירות Nginx אמור להגיב.
יתרון וחסרונות של IP חיצוני
להלן היתרונות והחסרונות של IP חיצוני:
זה יתרון להשתמש ב-IP חיצוני מכיוון:
-
- ה-IP שלך לגמרי בשליטתך. במקום להשתמש ב-ASN של ספק הענן, ייתכן שתשתמש ב-IP ששייך ל-ASN שלך.
החסרונות של IP חיצוני כוללים את הדברים הבאים:
-
- ההגדרה הפשוטה שנעבור כעת אינה זמינה במיוחד. זה מרמז שאם הצומת נכשל, השירות לא יהיה נגיש יותר ותצטרך לתקן את הבעיה באופן ידני.
- כדי לטפל בכתובות ה-IP, נדרשת עבודה אנושית רבה. מכיוון שכתובות ה-IP אינן מוקצות עבורך באופן דינמי, עליך לעשות זאת באופן ידני.
מהי ברירת מחדל של דחייה/אפשר התנהגות?
ה ' ברירת המחדל לאפשר ” מציין שכל התעבורה מותרת כברירת מחדל. אלא אם כן מותר במפורש, כל התנועה נדחתה כברירת מחדל בעת שימוש במונח ' הכחשה כברירת מחדל .' למעט כאשר צוינה מדיניות רשת.
-
- כל התעבורה אל הפוד וממנו מותרת אם אין מדיניות רשת בתוקף עבור הפוד הזה.
- אם מדיניות רשת אחת או יותר תקינה עבור כניסת תרמילים מסוג זה, רק תעבורת כניסה המותרת במפורש על ידי מדיניות זו מותרת.
- כאשר מדיניות רשת אחת או יותר חלה על תרמיל מסוג יציאה, אז רק תעבורת היציאה המותרת על ידי מדיניות זו מותרת.
הגדרת ברירת המחדל עבור סוגי נקודות קצה אחרים (VMs, ממשקי מארח) היא חסימת תעבורה. רק תעבורה המותרת באופן ספציפי על ידי מדיניות הרשת מותרת, גם אם לא חלה מדיניות רשת על נקודת הקצה.
שיטות עבודה מומלצות: מדיניות דחיית ברירת מחדל משתמעת
עליך להגדיר מדיניות דחיית ברירת מחדל מרומזת שנוצרה עבור התרמילים של Kubernetes. זה מוודא שתנועה לא רצויה נחסמת אוטומטית. זכור שמדיניות דחיית ברירת מחדל מרומזת תמיד נכנסת לתוקף אחרונה; אם כל מדיניות אחרת מאפשרת את התנועה, הדחייה אינה חלה. ההכחשה מיושמת רק לאחר שקילת כל שאר המדיניות.
כיצד ליצור מדיניות דחיית ברירת מחדל עבור Kubernetes Pods?
אנו ממליצים להשתמש במדיניות הרשת הגלובלית גם אם ניתן להשתמש בכל אחד מהכללים הבאים כדי לבנות מדיניות דחיית ברירת מחדל עבור תרמי Kubernetes. מדיניות רשת גלובלית חלה על כל עומסי העבודה (VMs ומכולות) בכל מרחבי השמות והמארחים. מדיניות רשת גלובלית מעודדת גישה זהירה לאבטחה תוך הגנה על משאבים.
-
- אפשר ברירת מחדל כדי לדחות מדיניות רשת גלובלית, ללא רווחי שמות
- אפשר כברירת מחדל כדי לדחות מדיניות רשת, מרווח שמות
- אפשר ברירת מחדל כדי לדחות את מדיניות Kubernetes, ברווח שמות
מה זה חסימת IP?
עם זאת, טווחי IP CIDR ספציפיים נבחרים להיות מותרים כמקורות כניסה או יעדי יציאה. בהתחשב בכך שכתובות IP של Pod הן ארעיות ובלתי ניתנות לחיזוי, אלו צריכים להיות כתובות IP חיצוניות לאשכולות.
לעתים קרובות יש לשכתב את המקור או היעד IP של מנות בעת שימוש בשיטות כניסה ויציאה לאשכולות. בהתאם לתוסף הרשת המסוים (ספק שירותי ענן, הטמעת שירות וכו') שבו נעשה שימוש, ההתנהגות עשויה להשתנות.
זה נכון לכניסה וזה אומר שבמקרים מסוימים עליך לסנן מנות נכנסות המבוססות על ה-IP המקור בפועל. מצד שני, 'ה-IP המקור' שעליו פועלת ה-NetworkPolicy עשוי להיות ה-IP של LoadBalancer או אפילו הצומת של הפוד וכו'.
זה מראה שחיבורים בין פודים וכתובות IP של שירות שנכתבו מחדש לכתובות IP חיצוניות לאשכולות עשויים להיות נתונים להגבלות מבוססות ipBlock מבחינת יציאה.
מהן מדיניות ברירת המחדל?
כל תעבורת כניסה ויציאה מ-pods וממנה במרחב שמות מותרת, כברירת מחדל, אם אין פקדים עבור מרחב שמות זה. אתה יכול לשנות את התנהגות ברירת המחדל של מרחב השמות באמצעות הדוגמאות הבאות.
ברירת מחדל דחיית כל תנועה נכנסת
בעת יצירת מדיניות רשת שבוחרת את כל הפודים אך אינה כוללת תעבורה נכנסת לאותם פודים, אתה יכול לבנות מדיניות בידוד כניסה 'ברירת מחדל' והיא מיועדת למרחב שמות.
זה מבטיח שכל התרמילים, ללא קשר אם מדיניות רשת אחרת כלשהי תבחר בהם, מבודדים לכניסה. כלל זה אינו חל על בידוד ליציאה מכל תרמיל.
ברירת מחדל דחיית כל תעבורת יציאה
כאשר אתה יוצר NetworkPolicy שבוחר את כל הפודים אך אוסר על תעבורת יציאה מאותם תרמילים, אתה יכול לבנות מדיניות בידוד יציאה 'ברירת מחדל' והיא מיועדת גם למרחב שמות.
סיכום
מדריך זה עוסק כולו בשימוש ב-DenyServiceExternalIPs. תכננו ייצוג דיאגרמטי גם כדי לגרום למשתמשים שלנו להבין שהוא עובד. סיפקנו גם תצורות לדוגמה.