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

באשכולות של Google Kubernetes Engine‏ (GKE) עם רשתות וירטואליות פרטיות (VPC), צמתים ללא כתובות 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

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

Configuration פתרון בעיות
‫Cloud NAT מוגדר כך שיחול רק על טווח כתובות ה-IP הראשי של תת-הרשת. כש-Cloud NAT מוגדר רק לטווח הכתובות הראשי של תת-הרשת, לחבילות שנשלחות מהאשכול לכתובות IP חיצוניות צריכה להיות כתובת IP של צומת מקור. בהגדרת Cloud NAT הזו:
  • אפשר לשלוח מ-Pods חבילות לכתובות IP חיצוניות אם כתובות ה-IP החיצוניות האלה כפופות להסוואת IP. כשפורסים את ip-masq-agent, מוודאים שרשימת nonMasqueradeCIDRs לא מכילה את כתובת ה-IP והיציאה של היעד. מנות שנשלחות ליעדים האלה עוברות קודם המרה לכתובות IP של צומת המקור לפני שהן מעובדות על ידי Cloud NAT.
  • כדי לאפשר ל-Pods להתחבר לכל כתובות ה-IP החיצוניות באמצעות הגדרת Cloud NAT הזו, צריך לוודא ש-ip-masq-agent נפרס ושרשימת nonMasqueradeCIDRs מכילה רק את טווחי כתובות ה-IP של הצומת וה-Pod של האשכול. מנות שנשלחות ליעדים מחוץ לאשכול מומרות קודם לכתובות IP של צומת המקור לפני שהן מעובדות על ידי Cloud NAT.
  • כדי למנוע מ-Pods לשלוח מנות לכתובות IP חיצוניות מסוימות, צריך לחסום את הכתובות האלה באופן מפורש כדי שלא יוסתרו. אחרי הפריסה של ip-masq-agent, מוסיפים את כתובות ה-IP החיצוניות שרוצים לחסום לרשימה nonMasqueradeCIDRs. מנות שנשלחות ליעדים האלה יוצאות מהצומת עם כתובות ה-IP המקוריות של ה-Pod. כתובות ה-IP של ה-Pod מגיעות מטווח כתובות 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.
  • כדי לאפשר ל-Pods להתחבר לכל כתובות ה-IP החיצוניות באמצעות הגדרת Cloud NAT הזו, צריך לוודא ש-ip-masq-agent נפרס ושהרשימה nonMasqueradeCIDRs גדולה ככל האפשר (0.0.0.0/0 מציין את כל כתובות ה-IP של היעדים). מנות שנשלחות לכל היעדים שומרות על כתובות ה-IP של ה-Pod המקורי לפני העיבוד על ידי Cloud NAT.

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

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

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