הגדרת קישוריות של פוד GKE לנקודת קצה חיצונית

במאמר הזה מוסבר איך להגדיר קישוריות מ-Pods ב-GKE לנקודות קצה חיצוניות, כולל משאבים ברשתות מקומיות ושירותי אינטרנט ציבוריים. כדי לשלוט בכתובת ה-IP המקורית של תעבורת ה-Pod ב-GKE, אפשר להשתמש גם ב-ip-masq-agent (תרגום ברמת הצומת) וגם ב-Cloud NAT (יציאה ברמת ה-VPC).

סקירה כללית

כש-Pod באשכול GKE מקורי של VPC שולח חבילה ליעד מחוץ לאשכול, כתובת ה-IP של המקור בחבילה משתנה בהתאם להגדרות של סוכן ההסוואה של כתובת ה-IP ברמת הצומת (ip-masq-agent) ושל Cloud NAT.

  1. תרגום ברמת הצומת (ip-masq-agent): מתרגם את כתובת ה-IP של המקור של חבילת הנתונים מכתובת ה-IP של ה-Pod (טווח משני של רשת משנה) לכתובת ה-IP הפנימית של הצומת (טווח ראשי של רשת משנה) על סמך רשימה מוגדרת של nonMasqueradeCIDRs.
  2. שער ברמת ה-VPC‏ (Cloud NAT): מתרגם כתובות IP פנימיות של VPC (כתובות IP של צמתים או כתובות IP של Pod) לכתובות IP ציבוריות סטטיות כדי לאפשר גישה לאינטרנט לדואר יוצא.

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

איך מסכות IP ו-Cloud NAT פועלים יחד

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

אם כתובת ה-IP של היעד לא תואמת לאף טווח ברשימה nonMasqueradeCIDRs:

  • ‫ip-masq-agent מבצע Source NAT ‏ (SNAT) בצומת GKE. כתובת ה-IP של המקור נכתבת מחדש מכתובת ה-IP של ה-Pod לכתובת ה-IP של הצומת.
  • חבילת הנתונים נכנסת לרשת ה-VPC עם כתובת ה-IP של הצומת כמקור.
  • שער Cloud NAT מיירט את החבילה.
  • שירות Cloud NAT מתרגם את כתובת ה-IP של הצומת לכתובת IP ציבורית ומנתב אותה לאינטרנט.

תרחיש ב': שמירה על כתובת ה-IP של ה-Pod (ללא הסוואה)

אם כתובת ה-IP של היעד תואמת לטווח ברשימה nonMasqueradeCIDRs (או אם SNAT ברירת המחדל מושבת):

  • המסנן ip-masq-agent לא משנה את החבילה. כתובת ה-IP של המקור נשארת כתובת ה-IP של ה-Pod.
  • חבילת הנתונים נכנסת לרשת ה-VPC עם כתובת ה-IP של ה-Pod כמקור.
  • שער Cloud NAT מיירט את החבילה.
  • ‫Cloud NAT מתרגם את כתובת ה-IP של ה-Pod לכתובת IP ציבורית רק אם הוא מוגדר במפורש לתרגם את טווח כתובות ה-IP המשני של רשת המשנה שמשמש את ה-Pods של GKE.

כלי לבדיקת הסתרת IP

אפשר להשתמש בכלי הזה כדי לבדוק אם כתובת IP של יעד תוסתר על סמך ההגדרה של ip-masq-agent.

דוגמה לזרימת תנועה

כדי להבין את נתיב התרגום, כדאי לעיין בהגדרות לדוגמה הבאות:

  • טווח כתובות ה-IP של ה-Pod: 10.4.0.0/14 (כתובת ה-IP של ה-Pod: 10.4.0.5)
  • טווח כתובות ה-IP של הצומת: 10.128.0.0/20 (כתובת ה-IP של הצומת: 10.128.0.10)
  • כתובת ה-IP של היעד: 8.8.8.8 (שרת DNS ציבורי, לא ברשימה nonMasqueradeCIDRs)

כש-Pod שולח מנה, קורה הדבר הבא:

  1. החבילה מתחילה ב-Pod: החבילה מגיעה מממשק הרשת של ה-Pod (כתובת ה-IP: 10.4.0.5) עם כתובת IP של יעד 8.8.8.8.
  2. הסוואה ברמת הצומת: מכיוון שכתובת ה-IP של היעד 8.8.8.8 לא נמצאת ברשימה nonMasqueradeCIDRs, המערכת ip-masq-agent בצומת המארח מיירטת את המנה כשהיא יוצאת ומבצעת SNAT. כתובת ה-IP של המקור נכתבת מחדש מכתובת ה-IP של Pod‏ 10.4.0.5 לכתובת ה-IP של צומת המארח, שהיא 10.128.0.10.
  3. ‫VPC egress: חבילת הנתונים מגיעה לרשת ה-VPC באמצעות כתובת ה-IP של צומת המארח 10.128.0.10 ככתובת ה-IP של המקור.
  4. ‫Cloud NAT gateway: מכיוון שהיעד הוא האינטרנט הציבורי, Cloud NAT מעבד את החבילה, מתרגם את כתובת ה-IP של המקור מ-10.128.0.10 לכתובת IP ציבורית של NAT (לדוגמה, 203.0.113.1) ומעביר אותה לאינטרנט.
  5. טיפול בתשובה: התשובה חוזרת לכתובת ה-IP הציבורית של Cloud NAT, ו-Cloud NAT מבצע תרגום הפוך בחזרה לכתובת ה-IP של צומת המארח 10.128.0.10. הצומת מבצע תרגום הפוך של כתובת ה-IP של צומת המארח בחזרה לכתובת ה-IP של ה-Pod, שהיא 10.4.0.5, ומעביר אותה למאגר ה-Pod.

זרימת תעבורה עם Cloud Service Mesh‏ (CSM)

אם עומסי העבודה שלכם משתמשים ב-Cloud Service Mesh, ניתוב התנועה מתבצע באופן הבא:

  • הפניית CNI ללא קובץ עזר חיצוני או באמצעות קובץ עזר חיצוני: מנות יוצאות מקונטיינר האפליקציה נחטפות על ידי הרשת (באמצעות קובץ עזר חיצוני כמו Envoy, או באמצעות הפניית CNI או הפנייה מבוססת ebpf) לפני שהן מגיעות למרחב השמות של הרשת בצומת.
  • החלת המדיניות: הרשת קובעת אם החיבור מותר על סמך מדיניות ההרשאות ותעבורת הנתונים היוצאת שלה.
  • ניתוב תעבורה יוצאת:
    • אם התעבורה מנותבת באמצעות שער יציאה (egress) של Cloud Service Mesh, כתובת ה-IP של המקור של המנה שעוזבת את הצומת תהיה כתובת ה-IP של הצומת או ה-Pod של שער היציאה, ולא של ה-Pod המקורי.
    • אם התעבורה מנותבת ישירות לנקודת הקצה החיצונית, החבילה יוצאת מהפרוקסי ומנותבת דרך מחסנית הרשת של צומת המארח הרגיל. במקרה כזה, כללי המדיניות וההגדרות של Cloud NAT שמתוארים קודם במסמך הזה עדיין חלים על תעבורת הנתונים היוצאת.ip-masq-agent
  • מידע נוסף על הגדרת ניתוב, שערים וניהול תנועה חיצונית ב-Cloud Service Mesh זמין במסמכי Cloud Service Mesh.

פתרון בעיות בקישוריות ובידודן

אם Pod לא מצליח להתחבר לנקודת קצה חיצונית ואתם משתמשים ב-Service mesh, עליכם לבודד אם הבעיה היא בהגדרת ה-Service mesh או בניתוב הבסיסי של GKE. כדי לבודד את הבעיה, אפשר להשתמש בשיטה הבאה:

  1. עקיפת רשת שירותים: אפשר לפרוס Pod לקוח זמני במרחב שמות שבו השבתתם את הזרקת ה-sidecar, או להשתמש בהערת sidecar.istio.io/inject: "false" במפרט ה-Pod כדי למנוע הזרקה של עומס העבודה של הבדיקה.
  2. בדיקת הקישוריות: מנסים להתחבר ליעד החיצוני (לדוגמה, באמצעות curl,‏ ping או nc) מה-Pod שאינו רשת.
  3. ניתוח התוצאות:
    • אם החיבור מצליח: הניתוב ברשת הבסיסית של GKE, כללי ip-masq-agent והשער של Cloud NAT מוגדרים בצורה נכונה. החסימה של הקישוריות נגרמת בגלל מדיניות Cloud Service Mesh, כללי יציאה חסרים או כללי mTLS. מידע נוסף על פתרון בעיות זמין במאמר פתרון בעיות בפריסות שמשתמשות ב-Envoy במאמרי העזרה של Cloud Service Mesh.
    • אם החיבור נכשל: הבעיה קשורה לתשתית הרשת הבסיסית (למשל, הסוואת כתובות IP, ‏ Cloud Router, ‏ Cloud NAT, כללי חומת אש של VPC או חומות אש מקומיות). כדי לבדוק את הגדרות הניתוב, פועלים לפי השלבים שבדף הזה.

קובעים את טווח כתובות ה-IP של המקור באמצעות הכלי לבדיקה

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

  1. מדביקים את תוכן ה-YAML של ip-masq-agent ConfigMap בשדה ההגדרה.
  2. מזינים את כתובת ה-IP של יעד נקודת הקצה (למשל, מסד נתונים מקומי או שירות אינטרנט חיצוני).
  3. לוחצים על Check Masquerading (בדיקת התחזות).
  4. שימו לב לפלט:
    • ‫Masqueraded: חבילת הנתונים משתמשת בטווח כתובות ה-IP של הצומת כמקור.
    • ‫Not masqueraded: חבילת הנתונים משתמשת בטווח כתובות ה-IP של ה-Pod כמקור.

הגדרת קישוריות לנקודות קצה

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

נקודות קצה מקומיות (VPN או Interconnect)

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

אם התנועה מוסתרת (המקור הוא כתובת ה-IP של הצומת):

  1. ‫Cloud Router: מוודאים שהפרסומים של Cloud Router כוללים את טווח כתובות ה-IP הראשי של תת-הרשת של אשכול GKE.
  2. נתב או חומת אש מקומיים: מגדירים את הנתבים וחומות האש המקומיים כך שיאפשרו ויטפלו בתעבורה נכנסת מטווח כתובות ה-IP של הצמתים ב-GKE.

אם התעבורה לא מוסתרת (המקור הוא כתובת ה-IP של ה-Pod):

  1. ‫Cloud Router: מגדירים פרסום של מסלולים בהתאמה אישית ב-Cloud Router כדי לפרסם את טווח כתובות ה-IP המשניות של ה-Pod ב-GKE ברשת המקומית.
  2. נתב או חומת אש מקומיים: מגדירים טבלאות ניתוב מקומיות וחומות אש כדי לאפשר תעבורה שמקורה בטווח כתובות ה-IP של ה-Pod ב-GKE, ומוודאים שהנתיבים להחזרת התעבורה מפורסמים בחזרה ל-VPC.

נקודות קצה באינטרנט (Cloud NAT)

כשמנתבים תעבורה לנקודות קצה באינטרנט הציבורי, צריך להגדיר שער Cloud NAT בתוך ה-VPC.

  1. נכנסים לדף Cloud NAT במסוף Cloud de Confiance .
  2. בוחרים או יוצרים שער Cloud NAT.
  3. בקטע מקור Cloud NAT, בוחרים איך השער מטפל בטווחים של רשתות משנה ב-GKE:
    • אם התנועה מוסתרת (המקור הוא כתובת ה-IP של הצומת): בוחרים באפשרות טווחים של כתובות IP ראשיות של רשת המשנה. בדרך כלל, פריסות מסחריות של GKE מוגדרות כברירת מחדל לשימוש בהגדרה הזו.
    • אם התנועה לא מוסתרת (המקור הוא כתובת ה-IP של ה-Pod): צריך לבחור באפשרות Primary and secondary IP address ranges (או לציין במפורש את הטווח המשני של ה-Pod ב-GKE). אם בוחרים רק טווחים ראשיים, תעבורת האינטרנט של ה-Pod של GKE תיחסם.