פתרון בעיות ב-Cloud NAT

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

לפני שמתחילים

כדי לפתור בעיות בהגדרות של Cloud NAT, צריך:

• התפקידים הנדרשים לניהול זהויות והרשאות גישה. מבקשים מהאדמין של הפרויקט ב-IAM להקצות לכם אחד מהתפקידים הבאים או את שניהם:
  • צפייה ב-Cloud NAT‏ (cloud-nat-viewer): התפקיד הזה נותן גישה לקריאה בלבד למשאבי Cloud NAT. התפקיד הזה מאפשר לכם להתחיל לאבחן את הבעיה.
  • ‫Cloud NAT Developer (cloud-nat-developer): התפקיד הזה נותן למפעילי האפליקציות את ההרשאות שנדרשות כדי ליצור, לקרוא, לעדכן ולמחוק (CRUD) אובייקטים של Cloud NAT בפרויקטים שהוקצו להם. התפקיד הזה מאפשר לבצע הרבה מהתיקונים שמתוארים בדף הזה.
  • יכול להיות שתצטרכו תפקידים נוספים כדי לבצע פעולות אבחון ותיקונים מסוימים.

אבחון ראשוני

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

פקודה:

kubectl get cloudnatgateway GATEWAY_NAME -n PROJECT_NAMESPACE -o yaml

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

• ‫GATEWAY_NAME: השם של המשאב ב-CloudNatGateway.
• ‫PROJECT_NAMESPACE: מרחב השמות של הפרויקט.

בודקים את תנאי הסטטוס: בשער תקין, כל התנאים הבאים צריכים להיות מוגדרים כ-True:

• ‫Ready: סטטוס התקינות הגלובלי.
• ‫SubnetsReady: ההגדרה של מאגר כתובות ה-IP תקינה.
• ‫PerimeterConfigurationReady: תשתית הרשת במעלה הזרם מוגדרת.
• ‫EgressRoutesReady: מדיניות הניתוב של הפודים פעילה.

אם אחד מהם הוא False, בודקים את השדות reason ו-message בפלט הסטטוס ופונים לטבלאות שבקטעים הבאים.

הפניה לקוד השגיאה ופתרון הבעיה

קודי השגיאה שמוחזרים על ידי kubectl get cloudnatgateway מתחלקים לשלוש קטגוריות עיקריות.

שגיאות ברשת המשנה (SubnetsReady הוא False)

התנאי הזה מצביע על בעיות במאגר כתובות ה-IP שהוקצה לשער.

קוד שגיאה	מה זה אומר	שלבים לתיקון הבעיה
CloudNATSelectorFieldOverlapsCode	התנגשות בהגדרות. ה-workloadSelector של השער הזה תואם לאותם עומסי עבודה כמו שער אחר בפרויקט. אי אפשר לנתב את התנועה באופן דטרמיניסטי.	מציגים את כל שערי Cloud NAT בפרויקט: kubectl get cloudnatgateway השוואה בין workloadSelector של השער הזה לבין שערים אחרים. משנים את התוויות כך שאף Pod או VM לא ייבחרו על ידי יותר משער אחד.
CloudNATSubnetRefsFieldInvalidCode	רשת המשנה לא תקינה. אי אפשר להשתמש ברשת המשנה שצוינה ב-subnetRefs. סיבות נפוצות: רשת המשנה לא קיימת. רשת המשנה לא במצב Ready. רשת המשנה היא לא מסוג Leaf.	מוודאים שרשת המשנה קיימת: kubectl get subnet <SUBNET_NAME> מוודאים שהסטטוס של רשת המשנה הוא Ready. מוודאים שרשת המשנה type היא Leaf (אי אפשר להשתמש ברשתות משנה של Root או Loopback ב-Cloud NAT).
CloudNATSubnetAlreadyInUseCode	התנגשות בין רשתות משנה. רשת המשנה שביקשתם כבר נמצאת ב "בעלות" של שער Cloud NAT אחר. אפשר לצרף רשת משנה רק לשער אחד בכל פעם.	צריך לבחור רשת משנה אחרת לשער הזה. אפשר גם להסיר קודם את רשת המשנה מהשער השני.
UNETAPIServerErrorCode	שגיאת מערכת. הבקר לא יכול לתקשר עם שרת ה-API כדי לאמת את רשתות המשנה.	פעולה: כנראה מדובר בבעיה זמנית בפלטפורמה. אם הבעיה נמשכת, צריך לפנות לאדמין של הפלטפורמה.

שגיאות בהגדרת ההיקף (PerimeterConfigurationReady הוא False)

התנאי הזה משקף את הסטטוס של שערי ההיקף.

קוד שגיאה	מה זה אומר	שלבים לתיקון הבעיה
NET-E0305	התנגשות בהגדרות. (כמו למעלה). בוררים חופפים מונעים מהמערכת לחשב את קבוצת הניתוב הנכונה.	מציגים את כל שערי Cloud NAT בפרויקט: kubectl get cloudnatgateway השוואה בין workloadSelector של השער הזה לבין שערים אחרים. משנים את התוויות כך שאף Pod או VM לא ייבחרו על ידי יותר משער אחד.
NET-E0301	מיצוי משאבים / כשל בצומת. המערכת יצרה את ההגדרה, אבל לא הצליחה להקצות את כתובות ה-IP של תעבורת הנתונים היוצאת לצומת פיזי תקין. בדרך כלל זה אומר שנגמרו כתובות ה-IP ברשת המשנה או שצומתי השער מושבתים.	בודקים את השימוש ב[רשת המשנה](/distributed-cloud/hosted/docs/latest/gdcag/platform/pa-user/subnets-overview). האם הוא מלא? אם ברשת המשנה יש כתובות IP פנויות והיא Ready, זה מצביע על כשל בתשתית בצד הפלטפורמה (למשל, אין צומתי שער תקינים זמינים). פעולה: פונים לאדמין של הפלטפורמה.
NET-E0001	שגיאת מערכת. כשל בתקשורת עם הבקר.	פעולה: פנו לאדמין של הפלטפורמה.

שגיאות במסלול התעבורה היוצאת (EgressRoutesReady הוא False)

התנאי הזה משקף את הסטטוס של מדיניות הניתוב בתוך האשכול.

קוד שגיאה	מה זה אומר	שלבים לתיקון הבעיה
NET-E0305	התנגשות בהגדרות. (כמו למעלה).	מציגים את כל שערי Cloud NAT בפרויקט: kubectl get cloudnatgateway השוואה בין workloadSelector של השער הזה לבין שערים אחרים. משנים את התוויות כך שאף Pod או VM לא ייבחרו על ידי יותר משער אחד.
NET-E0304	כשל בתכנות. המערכת לא הצליחה לתכנת את כללי המסלול (BPF) לכתובות ה-IP הספציפיות של השער.	פעולה: זו שגיאת תכנות פנימית או חוסר עקביות במצב. כדי להפעיל התאמה, נסו לבצע עדכון קטן בשער (למשל, לערוך תווית). אם הבעיה נמשכת, צריך לפנות לאדמין של הפלטפורמה.

בעיות נפוצות אחרות

אם סטטוס השער הוא Ready: True אבל התנועה עדיין נכשלת, כדאי לבדוק את הגדרות התצורה השגויות הנפוצות הבאות:

חסרה הרשאה ברמת הפרויקט

הפרויקט צריך לקבל הרשאה מפורשת לתעבורת נתונים יוצאת.

• בדיקה: האם למשאב Project יש את התווית networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true"?
• הפתרון: מבקשים מהאדמין של הפרויקט להחיל את התווית הזו.

חסרה הערת VM (מכונות וירטואליות בלבד)

המכונות הווירטואליות עוקפות את נתיב היציאה הרגיל של Pod, וצריך להורות להן במפורש להשתמש ב-Cloud NAT.

• בדיקה: האם לאובייקט VirtualMachineExternalAccess (VMEA) של המכונה הווירטואלית יש את ההערה egress.networking.gke.io/use-cloud-nat: "true"?
• תיקון: מוסיפים את ההערה לאובייקט VMEA.

תעבורת נתונים יוצאת (egress) מצומת אשכול רגיל

אם אתם מפעילים אשכול רגיל, הצמתים עצמם צריכים הרשאה לתעבורת נתונים יוצאת.

• בדיקה: האם לאובייקט Cluster יש את התווית cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true"?
• הפתרון: מבקשים מהאדמין של הפלטפורמה לתייג את אובייקט האשכול.

התנגשות בין Default Egress NAT לבין Cloud NAT

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

אבחון התנגשויות בין Pods

ב-Pods, בדרך כלל מפעילים את Default Egress NAT על ידי הוספת תווית ספציפית. ל-Pod לא יכולה להיות התווית הזו אם הוא גם מטורגט על ידי שער Cloud NAT.

1. זיהוי ה-Pod הרלוונטי: משיגים את התוויות של ה-Pod שבו יש בעיות בקישוריות.

   kubectl get pod <POD_NAME> -n <NAMESPACE> --show-labels
   

2. בודקים אם יש תוויות סותרות:

   • בחירת Cloud NAT: האם התוויות של ה-Pod תואמות ל-workloadSelector של CloudNatGateway כלשהו במרחב השמות?
   • תווית ברירת המחדל של תעבורת הנתונים היוצאת: האם ל-Pod יש את התווית egress.networking.gke.io/enabled: "true"?

   תנאי: אם שני התנאים מתקיימים, יש התנגשות.

3. פתרון: מסירים את תווית ברירת המחדל הקודמת של תעבורת הנתונים היוצאת מה-Pod (או מה-Deployment או ה-StatefulSet ההורה שלו) כדי לאפשר ל-Cloud NAT להשתלט על הבקרה הבלעדית.

אבחון התנגשויות במכונות וירטואליות

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

1. זיהוי ה-VMEA: מאתרים את האובייקט VirtualMachineExternalAccess שמשויך ל-VM.

   kubectl get vmea -n <NAMESPACE>
   

2. בודקים אם חסרה הערה:

   • בחירת Cloud NAT: האם התוויות של המכונה הווירטואלית תואמות ל-CloudNatGateway?
   • הערה לגבי הצטרפות: בודקים אם ההערה egress.networking.gke.io/use-cloud-nat: "true" מופיעה ב-VMEA.

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

3. פתרון: מוסיפים את ההערה לאובייקט VMEA.

   kubectl annotate vmea <VMEA_NAME> -n <NAMESPACE> egress.networking.gke.io/use-cloud-nat="true"