פתרון בעיות של אובדן מנות ב-Cloud NAT מאשכול

באשכולות של Google Kubernetes Engine‏ (GKE) שמוגדרים כ-VPC-native, צמתים ללא כתובות IP חיצוניות משפרים את האבטחה. הצמתים האלה משתמשים ב-Cloud NAT לחיבורים יוצאים לאינטרנט. אובדן מנות יכול לקרות אם מכונת VM של צומת ממצה את כתובות ה-IP והיציאות של Cloud NAT שהוקצו לה, לרוב בעומס גבוה של תעבורת נתונים יוצאת, ומשבש את תעבורת הנתונים היוצאת.

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

המידע הזה חשוב למנהלים ולמפעילים של פלטפורמות, ולמנהלי רשתות שמנהלים אשכולות GKE עם צמתים ללא גישה לאינטרנט, ומסתמכים על Cloud NAT לקישוריות חיצונית. מידע נוסף על התפקידים הנפוצים ומשימות לדוגמה שאליהם אנחנו מתייחסים בGoogle Cloud תוכן, זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

אבחון אובדן מנות

בקטעים הבאים מוסבר איך לרשום ביומן מנות שהושמטו באמצעות Cloud Logging, ואיך לאבחן את הסיבה להשמטת מנות באמצעות Cloud Monitoring.

תיעוד חבילות שנמחקו

אפשר לרשום ביומן מנות שהושמטו באמצעות השאילתה הבאה ב-Cloud Logging:

resource.type="nat_gateway"
resource.labels.region=REGION
resource.labels.gateway_name=GATEWAY_NAME
jsonPayload.allocation_status="DROPPED"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: שם האזור שבו נמצא האשכול.
  • ‫GATEWAY_NAME: השם של שער Cloud NAT.

הפקודה הזו מחזירה רשימה של כל החבילות שנמחקו על ידי שער Cloud NAT, אבל לא מזהה את הסיבה.

מעקב אחרי הסיבות לאובדן מנות

כדי לזהות את הסיבות לאובדן מנות, שולחים שאילתה אל הכלי למעקב אחרי מדדים ב-Cloud Monitoring. יש שלוש סיבות אפשריות לנטישת מנות:

  • OUT_OF_RESOURCES
  • ENDPOINT_INDEPENDENT_CONFLICT
  • NAT_ALLOCATION_FAILED

כדי לזהות מנות שהושמטו בגלל קודי השגיאה OUT_OF_RESOURCES או ENDPOINT_ALLOCATION_FAILED, משתמשים בשאילתה הבאה:

fetch nat_gateway
  metric 'router.googleapis.com/nat/dropped_sent_packets_count'
  filter (resource.gateway_name == GATEWAY_NAME)
  align rate(1m)
  every 1m
  group_by [metric.reason],
    [value_dropped_sent_packets_count_aggregate:
       aggregate(value.dropped_sent_packets_count)]

אם מזהים מנות שנשמטות מהסיבות האלה, כדאי לעיין במאמרים Packets dropped with reason: out of resources ו-Packets dropped with reason: endpoint independent conflict לקבלת עצות לפתרון בעיות.

כדי לזהות חבילות שנמחקו בגלל קוד השגיאה NAT_ALLOCATION_FAILED, משתמשים בשאילתה הבאה:

fetch nat_gateway
  metric 'router.googleapis.com/nat/nat_allocation_failed'
  group_by 1m,
    [value_nat_allocation_failed_count_true:
       count_true(value.nat_allocation_failed)]
  every 1m

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

בדיקת ההגדרה של Cloud NAT

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

Configuration פתרון בעיות
‫Cloud NAT מוגדר כך שיחול רק על טווח כתובות ה-IP הראשי של רשת המשנה. כש-Cloud NAT מוגדר רק לטווח כתובות ה-IP הראשי של תת-הרשת, לחבילות שנשלחות מהאשכול לכתובות IP חיצוניות צריכה להיות כתובת IP של צומת מקור. בהגדרת Cloud NAT הזו:
  • אפשר לשלוח מ-Pods חבילות לכתובות IP חיצוניות אם כתובות ה-IP החיצוניות האלה כפופות להסוואת IP. כשפורסים את ip-masq-agent, צריך לוודא שכתובת ה-IP והיציאה של היעד לא נמצאות ברשימה nonMasqueradeCIDRs. חבילות שנשלחות ליעדים האלה מומרות קודם לכתובות ה-IP של צומת המקור, ורק אחר כך מעובדות על ידי Cloud NAT.
  • כדי לאפשר לפודים להתחבר לכל כתובות ה-IP החיצוניות באמצעות הגדרת Cloud NAT הזו, צריך לוודא ש-ip-masq-agent פרוס ושהרשימה nonMasqueradeCIDRs מכילה רק את טווחי כתובות ה-IP של הצומת והפוד של האשכול. מנות שנשלחות ליעדים מחוץ לאשכול מומרות קודם לכתובות IP של צומת המקור לפני שהן מעובדות על ידי Cloud NAT.
  • כדי למנוע מ-Pods לשלוח מנות לכתובות IP חיצוניות מסוימות, צריך לחסום את הכתובות האלה באופן מפורש כדי שלא יוסתרו. אחרי הפריסה של ip-masq-agent, מוסיפים לרשימה nonMasqueradeCIDRs את כתובות ה-IP החיצוניות שרוצים לחסום. חבילות שנשלחות ליעדים האלה יוצאות מהצומת עם כתובות ה-IP המקוריות של Pod. כתובות ה-IP של הפודים מגיעות מטווח כתובות IP משני של תת-הרשת של האשכול. בהגדרה הזו, שירות Cloud NAT לא יפעל בטווח המשני הזה.
‫Cloud NAT מוגדר להחלה רק על טווח כתובות ה-IP המשני של רשת המשנה שמשמש לכתובות IP של Pod.

כש-Cloud NAT מוגדר רק לטווח כתובות ה-IP המשני של רשת המשנה שמשמש את כתובות ה-IP של ה-Pod באשכול, לחבילות שנשלחות מהאשכול לכתובות IP חיצוניות צריכה להיות כתובת IP של Pod כמקור. בהגדרת Cloud NAT הזו:

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

הפחתת אובדן מנות

אחרי שתאבחנו את הסיבה לאובדן המנות, כדאי להשתמש בהמלצות הבאות כדי לצמצם את הסיכוי שהבעיה תחזור בעתיד:

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

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

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

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

    כדי להקטין את קצב החיבורים היוצאים מהאפליקציה, צריך לעשות שימוש חוזר בחיבורים פתוחים. שיטות נפוצות לשימוש חוזר בחיבורים כוללות איגוד חיבורים, ריבוב חיבורים באמצעות פרוטוקולים כמו HTTP/2 או יצירת חיבורים קבועים לשימוש חוזר במספר בקשות. מידע נוסף זמין במאמר בנושא יציאות וחיבורים.

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