השוואה בין מודלים של רשתות ב-GKE

במאמר הזה מתואר מודל הרשת שבו נעשה שימוש ב-Google Kubernetes Engine ‏ (GKE), ומוסבר איך הוא שונה ממודלים של רשתות בסביבות אחרות של Kubernetes. במסמך הזה מוסברים המושגים הבאים:

  • המודלים הנפוצים ביותר של רשתות שמשמשים בהטמעות שונות של Kubernetes.
  • מנגנוני הקצאת כתובות IP של מודלים נפוצים של רשתות.
  • היתרונות והחסרונות של כל מודל רשת.
  • תיאור מפורט של מודל הרשת שמוגדר כברירת מחדל ב-GKE.

המסמך מיועד לארכיטקטים של ענן, למהנדסי תפעול ולמהנדסי רשתות שאולי מכירים יישומי Kubernetes אחרים ומתכננים להשתמש ב-GKE. ההנחה במסמך הזה היא שאתם מכירים את Kubernetes ואת מודל הרשתות הבסיסי שלו. כדאי גם להכיר מושגים ברשתות כמו הקצאת כתובות IP, תרגום כתובות רשת (NAT), חומות אש ושרתי proxy.

במסמך הזה לא מוסבר איך לשנות את מודל הרשת של GKE שמוגדר כברירת מחדל כדי לעמוד במגבלות שונות של כתובות IP. אם יש לכם מחסור בכתובות IP כשאתם מעבירים נתונים ל-GKE, כדאי לעיין במאמר אסטרטגיות לניהול כתובות IP כשמעבירים נתונים ל-GKE.

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

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

  • לכל Pod צריכה להיות כתובת IP ייחודית.
  • יחידות Pod יכולות לתקשר עם יחידות Pod אחרות בכל הצמתים בלי להשתמש ב-NAT.
  • נציגים בצומת, כמו kubelet, יכולים לתקשר עם כל ה-Pods בצומת הזה.
  • תאי Pod ברשת המארחת של צומת יכולים לתקשר עם כל תאי ה-Pod בכל הצמתים בלי להשתמש ב-NAT.

פותחו יותר מ-20 יישומים שונים של מודל הרשת של Kubernetes שעומדים בדרישות האלה.

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

  • איך פודים יכולים לתקשר עם שירותים שאינם Kubernetes ברשת הארגונית.
  • איך פודים יכולים לתקשר עם אשכולות Kubernetes אחרים באותו ארגון.
  • האם נדרש NAT לתקשורת מחוץ לאשכול.
  • האם אפשר לעשות שימוש חוזר בכתובות IP של Pod באשכולות אחרים או במקומות אחרים ברשת הארגונית.

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

בטבלה הבאה מפורטים שלושת סוגי המודלים הנפוצים, ומימוש Kubernetes שבו הם משמשים:

שם הדגם של הרשת בשימוש בהטמעות האלה
משולב באופן מלא או שטוח
מצב איים או מצב מגשר
מבודד או עם air gap
  • לא נפוץ בשימוש בהטמעות של Kubernetes, אבל אפשר להשתמש בו בכל הטמעה כשהאשכול נפרס ברשת נפרדת או בענן וירטואלי פרטי (VPC)

כשמתואר במסמך הזה מודל רשת כזה, הכוונה היא להשפעה שלו על רשתות מקומיות מחוברות. עם זאת, אפשר להחיל את המושגים שמתוארים לגבי רשתות מקומיות מחוברות על רשתות שמחוברות באמצעות רשת וירטואלית פרטית (VPN) או באמצעות חיבור פרטי, כולל חיבורים לספקי ענן אחרים. ב-GKE, החיבורים האלה כוללים את כל הקישוריות דרך Cloud VPN או Cloud Interconnect.

מודל רשת משולב באופן מלא

המודל המשולב (או השטוח) של הרשת מאפשר תקשורת קלה עם אפליקציות מחוץ ל-Kubernetes ובאשכולות אחרים של Kubernetes. ספקי שירותי ענן גדולים מטמיעים בדרך כלל את המודל הזה כי הם יכולים לשלב בצורה הדוקה את הטמעת Kubernetes שלהם עם רשת מוגדרת באמצעות תוכנה (SDN).

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

התרשים הבא מציג את אפשרויות התקשורת בין ה-Pods במודל הרישות המשולב באופן מלא:

דיאגרמה של הרשת שמציגה את דפוסי התקשורת במודל הרשת המשולב באופן מלא.

בתרשים שלמעלה מוצג מודל רשת משולב באופן מלא, עם דפוסי התקשורת הבאים:

  • פודים באשכול Kubernetes יכולים לתקשר ישירות ביניהם.
  • יחידות Pod יכולות לתקשר עם יחידות Pod אחרות באשכולות אחרים, כל עוד האשכולות האלה נמצאים באותה רשת.
  • אין צורך ב-NAT כדי שה-Pods יתקשרו עם אפליקציות אחרות מחוץ לאשכול, בלי קשר לשאלה אם האפליקציות האלה נמצאות באותה רשת או ברשתות מקושרות.

הדיאגרמה מראה גם שטווח כתובות ה-IP של ה-Pod שונה בין אשכולות שונים.

זמינות

המודל של רשת משולבת באופן מלא זמין בהטמעות הבאות:

  • כברירת מחדל, GKE מטמיע את המודל הזה. מידע נוסף על ההטמעה הזו זמין בהמשך המאמר, בקטע מודל הרשת של GKE.
  • כברירת מחדל, Amazon EKS מיישם את המודל הזה. בהטמעה הזו, Amazon EKS משתמש בתוסף Amazon VPC Container Networking interface ‏ (CNI) ל-Kubernetes כדי להקצות כתובות IP של Pod ישירות ממרחב הכתובות של ה-VPC. תוסף ה-CNI מקצה כתובות IP מתת-הרשת שמוגדרת כברירת מחדל, שבה נמצאים הצמתים, או מתת-רשת בהתאמה אישית. כתובות ה-IP של הפודים לא מגיעות מטווח כתובות IP ייעודי לפודים לכל צומת.
  • ב-Azure, ‏ AKS מטמיע את המודל הזה כשמשתמשים ב-Azure CNI (רישות מתקדם). ההטמעה הזו לא מתבצעת בהתאם להגדרות ברירת המחדל. ביישום הזה, כל Pod מקבל כתובת IP מרשת המשנה. אפשר גם להגדיר את המספר המקסימלי של יחידות Pod לכל צומת. לכן, מספר כתובות ה-IP ששמורות מראש עבור ה-Pods בצומת הזה זהה למספר המקסימלי של ה-Pods לכל צומת.

יתרונות

השימוש במודל רשת משולב באופן מלא מציע את היתרונות הבאים:

  • נתוני טלמטריה טובים יותר. כתובות ה-IP של ה-Pod גלויות בכל הרשת. היכולת הזו לראות את הנתונים הופכת את נתוני הטלמטריה לשימושיים יותר מאשר במודלים אחרים, כי אפשר לזהות את ה-Pods גם מנתוני טלמטריה שנאספים מחוץ לאשכול.
  • הגדרה קלה יותר של חומת האש. כשמגדירים כללים של חומת אש, קל יותר להבחין בין תעבורת הנתונים של הצומת לבין תעבורת הנתונים של ה-Pod במודל הרשת המשולב באופן מלא מאשר במודלים אחרים.
  • תאימות משופרת. אפשר להשתמש ב-Pods כדי לתקשר באמצעות פרוטוקולים שלא תומכים ב-NAT.
  • ניפוי באגים משופר. אם חומת האש מאפשרת זאת, משאבים מחוץ לאשכול יכולים להגיע ל-Pods ישירות במהלך תהליך הניפוי באגים.
  • תאימות לרשתות שירות. ב-Service mesh, כמו Istio או Cloud Service Mesh, קל לתקשר בין אשכולות כי הפודים יכולים לתקשר ישירות זה עם זה. חלק מההטמעות של Service mesh תומכות רק בקישוריות בין Pod ברשתות Service mesh מרובות אשכולות.

חסרונות

לשימוש במודל רשת משולב באופן מלא יש את החסרונות הבאים:

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

מודל רשת במצב איים

מודל הרשת במצב אי-תלות (או מגשור) משמש בדרך כלל להטמעות של Kubernetes מקומיות שבהן אי אפשר לבצע אינטגרציה עמוקה עם הרשת הבסיסית. כשמשתמשים במודל רשת במצב איים, רכיבי Pod באשכול Kubernetes יכולים לתקשר עם משאבים מחוץ לאשכול דרך שער או שרת proxy כלשהו.

בתרשים הבא מוצגות אפשרויות תקשורת בין Podים במודל רישות במצב איים:

דיאגרמה של הרשת שמציגה את דפוסי התקשורת במודל הרשת במצב איים.

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

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

  • שימוש בצמתים כשערים. ההטמעה הזו נפוצה כשצמתים באשכול הם חלק מהרשת הקיימת, וכתובות ה-IP שלהם ניתנות לניתוב באופן מקורי ברשת הזו. במקרה הזה, הצמתים עצמם הם השערים שמספקים קישוריות מתוך האשכול לרשת הגדולה יותר. תעבורת נתונים יוצאת מ-Pod אל מחוץ לאשכול יכולה להיות מופנית לאשכולות אחרים או לאפליקציות שאינן Kubernetes, למשל כדי להתקשר לממשק API מקומי ברשת הארגונית. בתעבורת נתונים יוצאת (egress) זו, הצומת שמכיל את ה-Pod משתמש ב-source NAT (SNAT) כדי למפות את כתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת. כדי לאפשר לאפליקציות מחוץ לאשכול לתקשר עם שירותים בתוך האשכול, אפשר להשתמש בסוג השירות NodePort ברוב ההטמעות. ביישומים מסוימים, אפשר להשתמש בסוג השירות LoadBalancer כדי לחשוף שירותים. כשמשתמשים בסוג השירות LoadBalancer, מקצים לשירותים האלה כתובת IP וירטואלית שמתבצע איזון עומסים בינה לבין הצמתים, והיא מנותבת אל Pod ששייך לשירות.

    הדיאגרמה הבאה מציגה את דפוס ההטמעה בעת שימוש בצמתים כשערים:

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

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

    • איך פודים מתקשרים עם אשכולות אחרים או עם אפליקציות שאינן Kubernetes באמצעות SNAT כשהם יוצאים מהצומת.
    • איך תעבורה משירותים חיצוניים באשכולות אחרים או מאפליקציות שאינן Kubernetes נכנסת לאשכול דרך שירות NodePort לפני שהיא מועברת אל ה-Pod הנכון באשכול.

  • שימוש במכונות וירטואליות (VM) של שרת proxy עם כמה ממשקי רשת. תבנית ההטמעה הזו משתמשת בשרתי proxy כדי לגשת לרשת שמכילה את אשכול Kubernetes. לפרוקסי חייבת להיות גישה למרחב כתובות ה-IP של ה-Pod והצומת. בדפוס הזה, לכל מכונת proxy וירטואלית יש שני ממשקי רשת: ממשק אחד ברשת הארגונית הגדולה וממשק אחד ברשת שמכילה את אשכול Kubernetes.

    בתרשים הבא מוצג דפוס ההטמעה כשמשתמשים במכונות וירטואליות של שרת proxy:

    דיאגרמה של הרשת שמציגה את דפוסי התקשורת במודל הרשת במצב איים שמשתמש במכונות וירטואליות של proxy.

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

זמינות

מודל הרשת במצב אי-תלות זמין בהטמעות הבאות:

  • כברירת מחדל, Azure Kubernetes Service‏ (AKS) משתמש ברשת במצב איים כשמשתמשים ברשת Kubenet (בסיסית). כש-AKS משתמש ברישות במצב איים, הרשת הווירטואלית שמכילה את האשכול כוללת רק כתובות IP של צמתים. כתובות ה-IP של ה-Pod לא נכללות ברשת הווירטואלית. במקום זאת, ה-Pods מקבלים כתובות IP ממרחב לוגי אחר. מודל 'מצב אי' שבו נעשה שימוש ב-AKS גם מנתב תעבורת נתונים מ-Pod ל-Pod בין צמתים באמצעות ניתובים שהוגדרו על ידי המשתמש עם הפעלת העברת IP בממשק הצמתים. כדי שה-Pod יוכל לתקשר עם משאבים מחוץ לאשכול, הצומת משתמש ב-SNAT כדי למפות את כתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת לפני שתעבורת הנתונים היוצאת (egress) יוצאת מהצומת.
  • ב-Oracle Container Engine for Kubernetes ‏ (OKE), התקשורת בין קבוצות Pod מתבצעת באמצעות רשת שכבת-על של VXLAN. בנוסף, תעבורת הנתונים מ-Pods לאפליקציות מחוץ לאשכול משתמשת ב-SNAT כדי למפות את כתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת.

יתרונות

לשימוש במודל רשת במצב אי-תלות יש את היתרונות הבאים:

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

  • הגדרות אבטחה פשוטות יותר. מכיוון ש-Pods לא נחשפים ישירות לשאר הרשת הארגונית, לא צריך לאבטח את ה-Pods מפני תעבורת נתונים נכנסת (ingress) משאר הרשת הארגונית.

חסרונות

לשימוש במודל רשת במצב איים יש את החסרונות הבאים:

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

  • תאימות לרשתות שירות. במצב איים, אי אפשר ליצור תקשורת ישירה בין רכיבי Pod באשכולות שונים ב-Service mesh, כמו Istio או Cloud Service Mesh.

    יש הגבלות נוספות בהטמעות מסוימות של Service mesh. תמיכה בריבוי אשכולות ב-Cloud Service Mesh באשכולות GKE ב-Google Cloud תומכת רק באשכולות באותה רשת. בהטמעות של Istio שתומכות במודל מרובה רשתות, התקשורת צריכה להתבצע דרך Istio Gateways, מה שהופך את ה-Deployment (פריסה) של Service mesh מרובה אשכולות למורכבות יותר.

מודל של רשת מבודדת

מודל הרשת המבודדת (או עם air gap) משמש בדרך כלל לאשכולות שלא צריכים גישה לרשת הארגונית הגדולה יותר, אלא רק דרך ממשקי API שפונים לציבור. כשמשתמשים במודל של רשת מבודדת, כל אשכול Kubernetes מבודד ולא יכול להשתמש בכתובות IP פנימיות כדי לתקשר עם שאר הרשת. האשכול נמצא ברשת פרטית משלו. אם יש פודים באשכול שצריכים לתקשר עם שירותים מחוץ לאשכול, התקשורת הזו צריכה להתבצע באמצעות כתובות IP ציבוריות גם לתעבורת נתונים נכנסת (ingress) וגם לתעבורת נתונים יוצאת (egress).

התרשים הבא מציג אפשרויות תקשורת של Pod במודל של רשת מבודדת:

דיאגרמה של הרשת שבה מוצגים דפוסי התקשורת במודל הרשת המבודדת.

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

  • יש שער לאינטרנט שמחבר את האשכול לעולם החיצוני.
  • האפליקציה החיצונית משתמשת בכתובת IP חיצונית לתקשורת.

לבסוף, בתרשים מוצג איך אפשר לעשות שימוש חוזר באותו מרחב כתובות IP עבור Podים וצמתים בסביבות שונות.

זמינות

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

יתרונות

היתרונות של שימוש במצב רשת מבודד:

  • השימוש בכתובת ה-IP. אפשר לעשות שימוש חוזר בכל כתובות ה-IP הפנימיות באשכול: כתובות IP של צמתים, כתובות IP של שירותים וכתובות IP של Pod. אפשר לעשות שימוש חוזר בכתובות IP פנימיות כי לכל אשכול יש רשת פרטית משלו, והתקשורת עם משאבים מחוץ לאשכול מתבצעת רק דרך כתובות IP ציבוריות.
  • שליטה. לאדמינים של האשכול יש שליטה מלאה על הקצאת כתובות IP באשכול, והם לא צריכים לבצע משימות ניהול של כתובות IP. לדוגמה, אדמינים יכולים להקצות את כל מרחב הכתובות 10.0.0.0/8 ל-Pods ולשירותים באשכול, גם אם הכתובות האלה כבר נמצאות בשימוש בארגון.
  • אבטחה. התקשורת מחוץ לאשכול נשלטת בקפדנות, וכשהיא מותרת, היא מתבצעת באמצעות ממשקים חיצוניים מוגדרים היטב ו-NAT.

חסרונות

יש כמה חסרונות לשימוש במודל של רשת מבודדת:

  • אין תקשורת פרטית. אסור להשתמש בכתובות IP פנימיות כדי לתקשר עם אשכולות אחרים או עם שירותים אחרים ברשת.

מודל הרישות של GKE

‫GKE משתמש במודל רשת משולב לחלוטין שבו קלאסטרים נפרסים ברשת של ענן וירטואלי פרטי (VPC), שיכולה להכיל גם אפליקציות אחרות.

מומלץ להשתמש באשכול המותאם ל-VPC בסביבת GKE. אפשר ליצור אשכול המותאם ל-VPC במצב רגיל או במצב Autopilot. אם בוחרים במצב Autopilot, המצב 'מקומי ל-VPC' מופעל תמיד ואי אפשר להשבית אותו. בפסקאות הבאות מתואר מודל הרישות של GKE במצב Standard, עם הערות לגבי ההבדלים במצב Autopilot.

הסבר על ניהול כתובות IP באשכולות המותאמים ל-VPC

כשמשתמשים באשכול המותאם ל-VPC, כתובות ה-IP של ה-Pod הן כתובות IP משניות בכל צומת. לכל צומת מוקצית תת-רשת ספציפית מתוך טווח כתובות ה-IP של ה-Pod שאתם בוחרים מתוך מרחב כתובות ה-IP הפנימיות כשאתם יוצרים את האשכול. כברירת מחדל, באשכול המותאם ל-VPC מוקצית רשת משנה /24 לכל צומת לשימוש ככתובות IP של Pod. /24 תת-רשת מתאימה ל-256 כתובות IP. ב-Autopilot, האשכול משתמש ב/26 רשת משנה שתואמת ל-64 כתובות, ואי אפשר לשנות את הגדרת רשת המשנה הזו.

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

מכיוון שכתובות ה-IP של ה-Pods ניתנות לניתוב ברשת ה-VPC, ה-Pods יכולים לקבל תעבורת נתונים כברירת מחדל מהמשאבים הבאים:

ניהול תקשורת של תנועה חיצונית באמצעות סוכן IP masquerade

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

אפשר גם להשתמש בכתובות IP ציבוריות לשימוש פרטי (PUPI) בתוך רשת ה-VPC או ברשתות שמחוברות אליה. אם אתם משתמשים בכתובות PUPI, אתם עדיין יכולים ליהנות ממודל הרשת המשולב באופן מלא ולראות את כתובת ה-IP של ה-Pod ישירות כמקור. כדי להשיג את שתי המטרות האלה, צריך לכלול את כתובות ה-PUPI ברשימה nonMasqueradeCIDRs.

הסבר על זרימת התנועה של Pod ברשת GKE

בתרשים הבא מוצג האופן שבו Pods יכולים לתקשר במודל הרישות של GKE:

דיאגרמה של הרשת שמציגה את דפוסי התקשורת במודל הרשת של GKE.

בתרשים הקודם מוצג איך פודים בסביבות GKE יכולים להשתמש בכתובות IP פנימיות כדי לתקשר ישירות עם המשאבים הבאים:

  • ‫Pods אחרים באותו אשכול.
  • פודים באשכולות אחרים של GKE באותה רשת VPC.
  • אפליקציות אחרות Google Cloud באותה רשת VPC.
  • אפליקציות מקומיות שמחוברות דרך Cloud VPN.

בתרשים מוצג גם מה קורה כש-Pod צריך להשתמש בכתובת IP חיצונית כדי לתקשר עם אפליקציה. כשהתעבורה יוצאת מהצומת, הצומת שבו נמצא ה-Pod משתמש ב-SNAT כדי למפות את כתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת. אחרי שהתעבורה יוצאת מהצומת, Cloud NAT מתרגם את כתובת ה-IP של הצומת לכתובת IP חיצונית.

כדי ליהנות מהיתרונות שמתוארים בהמשך המאמר, ובמיוחד מהיתרון של כתובות IP של Pod שמוצגות בכל נתוני הטלמטריה, Google בחרה במודל רשת משולב לחלוטין. ב-GKE, כתובות ה-IP של ה-Pod נחשפות ביומנים לתיעוד מידע על תעבורת ה-IP של ענן וירטואלי פרטי (VPC) (כולל שמות ה-Pod במטא-נתונים), ברפליקציה של חבילות נתונים, בניהול כללי חומת אש וביומני האפליקציות שלכם ליעדים שלא מוסווים.

המאמרים הבאים