פתרון בעיות באיזון עומסים ב-GKE

בעיות באיזון העומסים ב-Google Kubernetes Engine‏ (GKE) עלולות לגרום לשיבושים בשירות, כמו שגיאות HTTP 502, או למנוע גישה לאפליקציות.

במאמר הזה מוסבר איך לפתור שגיאות 502 שמתקבלות מ-Ingress חיצוני, ואיך להשתמש ביומנים של איזון עומסים ובכלי אבחון כמו check-gke-ingress כדי לזהות בעיות.

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

תעבורת נתונים נכנסת (ingress) חיצונית גורמת לשגיאות HTTP 502

כדי לפתור שגיאות HTTP 502 במשאבי Ingress חיצוניים, אפשר להיעזר בהנחיות הבאות:

  1. מפעילים יומנים לכל שירות לקצה העורפי שמשויך לכל שירות GKE שאליו יש הפניה ב-Ingress.
  2. אפשר להשתמש בפרטי הסטטוס כדי לזהות את הסיבות לתגובות HTTP 502. פרטי הסטטוס שמציינים שהתגובה HTTP 502 הגיעה מהקצה העורפי מחייבים פתרון בעיות ב-Pods של ההגשה, ולא במאזן העומסים.

קבוצות לא מנוהלות של מכונות

יכול להיות שתיתקלו בשגיאות HTTP 502 במשאבי Ingress חיצוניים אם משאבי Ingress החיצוניים משתמשים בשרתי קצה של קבוצות מופעים לא מנוהלות. הבעיה הזו מתרחשת כשכל התנאים הבאים מתקיימים:

  • במאגר יש מספר גדול של צמתים בכל מאגרי הצמתים.
  • ה-Pods שמציגים את השירותים שאליהם מפנה ה-Ingress נמצאים רק בכמה צמתים.
  • השירותים שאליהם מפנה ה-Ingress משתמשים ב-externalTrafficPolicy: Local.

כדי לבדוק אם ה-Ingress החיצוני שלכם משתמש בקצה העורפי של קבוצת מופעים לא מנוהלת:

  1. עוברים לדף Ingress במסוף Cloud de Confiance .

    מעבר אל Ingress

  2. לוחצים על השם של ה-Ingress החיצוני.

  3. לוחצים על השם של מאזן העומסים. יוצג הדף Load balancing details.

  4. כדי לבדוק אם ה-Ingress החיצוני שלכם משתמש ב-NEGs או בקבוצות של מכונות וירטואליות, צריך לעיין בטבלה שבקטע שירות לקצה העורפי.

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

  • שימוש באשכול המותאם ל-VPC.
  • משתמשים ב-externalTrafficPolicy: Cluster לכל שירות שאליו מפנה ה-Ingress החיצוני. הפתרון הזה גורם לאובדן של כתובת ה-IP המקורית של הלקוח במקורות של החבילה.
  • משתמשים בהערה node.kubernetes.io/exclude-from-external-load-balancers=true. מוסיפים את ההערה לצמתים או למאגרי הצמתים שלא מריצים אף Pod של שרת לכל שירות שמפנה לכל Ingress חיצוני או לכל שירות LoadBalancer באשכול.

הגדרת רישום ביומן של מאזן עומסים בשכבה 4

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

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

בקר GKE L4LB מספק משוב על סטטוס ההתאמה של הרישום ביומן באמצעות הסוג status.conditions של השירות. כדי לבדוק את הסטטוס, מריצים את הפקודה הבאה:

kubectl get svc SERVICE_NAME -o yaml

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

  • ‫SERVICE_NAME: שם האשכול.

בפלט, מחפשים את סוג התנאי LoggingConfigManaged. בטבלה הבאה מפורטות הסיבות האפשריות למצב:

סטטוס התנאי סיבה תיאור
True מותאם הבקר אוכף באופן פעיל את הגדרות הרישום ביומן שמוגדרות ב-CRD‏ L4LBConfig.
לא נכון לא מנוהל הקטע logging חסר ב-CRD‏ L4LBConfig, או שההערה הוסרה. הבקר הפסיק את הניהול והשאיר את השירות לקצה העורפי במצב האחרון הידוע שלו.
לא נכון חסר לא נמצא המשאב L4LBConfig שאליו מפנה ההערה של השירות.
לא נכון לא חוקי המשאב L4LBConfig נכשל באימות הצולב של הפרמטר optionalFields.
לא נכון שגיאה אירעה שגיאה במהלך ההתאמה של שירות לקצה העורפי.

הסבר על התנהגות החוף

אם ההערה networking.gke.io/l4lb-config תוסר מהמניפסט של השירות, או אם המשאב L4LBConfig שאליו מפנים יימחק, ההגדרה תעבור למצב Coast.

במצב הזה, בקר GKE מפסיק לנהל את הגדרות הרישום ביומן, אבל לא מאפס את שירות הקצה העורפי של Cloud de Confiance by S3NS להגדרות ברירת המחדל שלו. במקום זאת, השירות לקצה העורפי נשאר במצב האחרון שהיה תקין. אירוע אזהרה מונפק בדרך כלל כדי להודיע לכם ש-Kubernetes כבר לא שולט בהגדרה.

שימוש ביומנים של מאזן העומסים לפתרון בעיות

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

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

  • שם האשכול
  • מיקום האשכול
  • שם השירות
  • מרחב השמות של השירות
  • שם ה-Pod
  • מרחב השמות של ה-Pod

שימוש בכלי אבחון כדי לפתור בעיות

כלי האבחון check-gke-ingress בודק משאבי Ingress כדי לזהות בעיות נפוצות בהגדרות. אפשר להשתמש בכלי check-gke-ingress בדרכים הבאות:

  • מריצים את כלי שורת הפקודה gcpdiag באשכול. תוצאות ה-Ingress מופיעות בקטע gke/ERR/2023_004 של כלל הבדיקה.
  • אפשר להשתמש בכלי check-gke-ingress לבד או כפלאגין של kubectl. כדי לעשות את זה, צריך לפעול לפי ההוראות שמפורטות ב-check-gke-ingress.