פתרון בעיות בבדיקות תקינות של Ingress

אם בדיקות תקינות של Ingress ב-Google Kubernetes Engine‏ (GKE) נכשלות, יכול להיות שהתנועה לא תגיע לאפליקציה שלכם, גם אם קבוצות ה-Pod פועלות.

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

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

איך פועלים בדיקות תקינות של Ingress

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

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

בדיקות התקינות של מאזן העומסים מוגדרות לכל שירות לקצה העורפי. אפשר להשתמש באותו בדיקת תקינות לכל שירותי ה-backend של איזון העומסים, אבל ההפניה לבדיקת התקינות לא מצוינת עבור כל איזון העומסים (באובייקט Ingress עצמו).

‫GKE יוצר בדיקות תקינות על סמך אחת מהשיטות הבאות:

  • ‫BackendConfig CRD: הגדרת משאב בהתאמה אישית (CRD) שמאפשרת לכם לשלוט באופן מדויק באינטראקציה של השירותים עם מאזן העומסים. BackendConfig CRD מאפשרים לציין הגדרות מותאמות אישית לבדיקת תקינות שמשויכת לשירות לקצה העורפי המתאים. ההגדרות המותאמות אישית האלה מספקות גמישות ושליטה רבות יותר בבדיקות התקינות של מאזן עומסים קלאסי של אפליקציות (ALB) ושל מאזן עומסים פנימי של אפליקציות (ALB) שנוצר על ידי Ingress.
  • בדיקת מוכנות: בדיקה אבחונית שקובעת אם קונטיינר בתוך Pod מוכן לטפל בתנועה. בקר GKE Ingress יוצר את בדיקת תקינות עבור שירות ה-Backend של השירות על סמך בדיקת המוכנות שמשמשת את ה-Pods של השירות. אפשר לגזור את הפרמטרים של בדיקת תקינות, כמו נתיב, יציאה ופרוטוקול, מההגדרה של בדיקת המוכנות.
  • ערכי ברירת מחדל: הפרמטרים שבהם נעשה שימוש כשלא מגדירים CRD או מאפיינים לבדיקת המוכנות.BackendConfig
שיטה מומלצת:

כדי לקבל את השליטה המקסימלית על הגדרות בדיקת התקינות של מאזן העומסים, כדאי להשתמש ב-BackendConfig CRD.

‫GKE משתמש בהליך הבא כדי ליצור בדיקת תקינות לכל שירות לקצה העורפי שמתאים לשירות Kubernetes:

  • אם השירות מפנה אל CRD‏ BackendConfig עם מידע על healthCheck, ‏ GKE משתמש במידע הזה כדי ליצור את בדיקת תקינות. גם בבקר GKE Enterprise Ingress וגם בבקר GKE Ingress יש תמיכה ביצירת בדיקות תקינות בדרך הזו.

  • אם השירות לא מפנה אל CRD‏ BackendConfig:

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

    • אם בתבנית ה-Pod של ה-Pods להצגת נתונים של השירות לא מוגדר קונטיינר עם בדיקת מוכנות שהמאפיינים שלה יכולים להתפרש כפרמטרים של בדיקת תקינות, ערכי ברירת המחדל ישמשו ליצירת בדיקת התקינות. גם בקר ה-Ingress של GKE Enterprise וגם בקר ה-Ingress של GKE יכולים ליצור בדיקת תקינות באמצעות ערכי ברירת המחדל בלבד.

לתשומת ליבכם

בקטע הזה מפורטים כמה שיקולים שכדאי לזכור כשמגדירים BackendConfig CRD או כשמשתמשים בבדיקת מוכנות.

BackendConfig CRD

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

  • אם אתם משתמשים באיזון עומסים מובנה בקונטיינר, צריך לוודא שהיציאה של בדיקת תקינות במניפסט BackendConfig תואמת לcontainerPort של Pod שמשרת.
  • לדוגמה, אם משתמשים בקצה עורפי של קבוצת מופעים, צריך לוודא שהיציאה של בדיקת תקינות בBackendConfigמניפסט תואמת לnodePort שנחשפת על ידי השירות.
  • ‫Ingress לא תומך ב-gRPC להגדרות מותאמות אישית של בדיקות תקינות. ב-BackendConfig אפשר ליצור בדיקות תקינות רק באמצעות הפרוטוקולים HTTP,‏ HTTPS או HTTP2. דוגמה לשימוש בפרוטוקול ב-BackendConfig CRD מופיעה ב-gke-networking-recipes.

מידע נוסף זמין במאמר מתי כדאי להשתמש ב-CRD של BackendConfig.

בקשה לבדיקת תקינות (probe) מוכנות

כשמשתמשים ב-GKE Ingress עם איזון עומסים של HTTP או HTTPS,‏ GKE שולח את בדיקות תקינות כדי לקבוע אם האפליקציה פועלת בצורה תקינה. בדיקות תקינות אלה נשלחות ליציאה הספציפית ב-Pods שהגדרתם בקטע spec.containers[].readinessProbe.httpGet.port בהגדרת ה-YAML של ה-Pod, בתנאי שהתנאים הבאים מתקיימים:

  • מספר היציאה של בדיקת המוכנות שצוין ב-spec.containers[].readinessProbe.httpGet.port חייב להיות זהה ליציאה בפועל שהאפליקציה מאזינה לה בקונטיינר, שמוגדרת בשדה containers[].spec.ports.containerPort בהגדרות של ה-Pod.
  • ה-containerPort של ה-Pod שמשרת את הבקשה חייב להיות זהה ל-targetPort של השירות. כך מוודאים שהתנועה מנותבת מהשירות ליציאה הנכונה ב-Pods.
  • מפרט יציאת העורף של השירות ב-Ingress חייב להפנות ליציאה חוקית מהקטע spec.ports[] בהגדרת השירות. אפשר לעשות זאת באחת משתי דרכים:
    • ‫spec.rules[].http.paths[].backend.service.port.name in the Ingress matches spec.ports[].name שמוגדר בשירות המתאים.
    • ‫spec.rules[].http.paths[].backend.service.port.number in the Ingress matches spec.ports[].port שמוגדר בשירות המתאים.

פתרון בעיות נפוצות בבדיקת התקינות

כדי לזהות בעיות בבדיקת תקינות, אפשר להיעזר בתרשים הזרימה הבא לפתרון בעיות:

פתרון בעיות שקשורות לבדיקות תקינות של Ingress.
איור: פתרון בעיות בבדיקות תקינות

בתרשים הזרימה הזה, ההנחיות הבאות לפתרון בעיות עוזרות לקבוע איפה הבעיה:

  1. בדיקת תקינות של ה-Pod: אם בדיקת התקינות נכשלת, צריך לבדוק את הסטטוס של ה-Pods של שרת השירות. אם ה-Pods לא פועלים ולא תקינים:

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

  2. רישום ביומן של בדיקות תקינות: מוודאים שהפעלתם את הרישום ביומן של בדיקות התקינות.

  3. בדיקת ההגדרות של חומת האש: מוודאים שכללי חומת האש מאפשרים לבדיקות תקינות להגיע ל-Pods. אם לא:

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

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

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

האפליקציה לא מגיבה לבדיקות תקינות

האפליקציה לא מגיבה עם קוד הסטטוס הצפוי (200 OK ל-HTTP או SYN, ACK ל-TCP) במהלך בדיקות התקינות בנתיב וביציאה שהוגדרו.

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

  • קבוצות של נקודות קצה ברשת(NEGs):
    • האפליקציה לא פועלת בצורה תקינה ב-Pod.
    • האפליקציה לא מאזינה ליציאה או לנתיב שהוגדרו.
    • יש בעיות בקישוריות לרשת שמונעות מהבדיקה להגיע ל-Pod.
  • קבוצת מופעים:
    • הצמתים בקבוצת המופעים לא תקינים.
    • האפליקציה לא פועלת בצורה תקינה בצמתים.
    • הבקשות לבדיקת התקינות לא מגיעות לצמתים.

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

ל-NEGs:

  1. כדי לגשת ל-Pod באמצעות kubectl exec:

    kubectl exec -it pod-name -- command

    הדגל -it מספק סשן אינטראקטיבי של מסוף (i לציון אינטראקטיבי, t לציון TTY).

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

    • ‫pod-name: השם של ה-Pod.
    • ‫command: הפקודה שרוצים להריץ בתוך ה-Pod. הפקודה הנפוצה ביותר היא bash או sh כדי לקבל מעטפת אינטראקטיבית.

  2. מריצים פקודות curl כדי לבדוק את הקישוריות ואת מהירות התגובה של האפליקציה:

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

לקבוצות של מופעים:

  1. מוודאים שהצמתים תקינים ומגיבים לבדיקות התקינות שמוגדרות כברירת מחדל.
  2. אם הצמתים תקינים אבל ה-Pod של האפליקציה לא מגיב, צריך לבדוק את האפליקציה לעומק.
  3. אם הבקשות לא מגיעות ל-Pods, יכול להיות שיש בעיה ברשת GKE. לקבלת עזרה, אפשר לפנות לתמיכה של Cloud de Confiance by S3NS .

שגיאה בעריכת בדיקת המוכנות ב-Pod

כשמנסים לערוך את בדיקת המוכנות ב-Pod כדי לשנות את הפרמטרים של בדיקת התקינות, מתקבלת שגיאה דומה לזו שמופיעה בהמשך:

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

אם משנים את בדיקת המוכנות של ה-Pods שמשויכים לשירות שכבר מקושר ל-Ingress (ולמאזן העומסים התואם שלו), GKE לא מעדכן אוטומטית את הגדרת בדיקת תקינות במאזן העומסים. התוצאה היא חוסר התאמה בין בדיקת המוכנות של ה-Pod לבין בדיקת התקינות של מאזן העומסים, שגורם לכשל בבדיקת התקינות.

כדי לפתור את הבעיה, צריך לפרוס מחדש את ה-Pods ואת משאב ה-Ingress. הפעולה הזו גורמת ל-GKE ליצור מחדש את מאזן העומסים (LB) ואת בדיקות התקינות שלו, ולשלב את ההגדרות החדשות של בדיקת המוכנות.

הפריסה ומאזן העומסים לא מתחילים

אם הפריסה לא מתחילה ושירותי ה-Backend שמאחורי איזון העומסים של בקר ה-Ingress מסומנים כלא תקינים, יכול להיות שהסיבה לכך היא כשל בבדיקת המוכנות.

יכול להיות שתופיע הודעת השגיאה הבאה שבה מוזכר כשל בבדיקת מוכנות:

Readiness probe failed: connection refused

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

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

  • מוודאים שהאפליקציה מוגדרת בצורה נכונה ומגיבה בנתיב ובפורט שצוינו בפרמטרים של בדיקת המוכנות.
  • בודקים את יומני האפליקציה ומנסים לפתור בעיות או שגיאות בהפעלה.
  • מוודאים שהיציאה containerPort בהגדרת ה-Pod זהה ליציאה targetPort בשירות וליציאת ה-Backend שצוינה ב-Ingress.

חסרים כללים אוטומטיים של חומת אש לתעבורת נתונים נכנסת (ingress)

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

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

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

  • מוודאים שכללי חומת האש של תעבורת הנתונים הנכנסת (ingress) קיימים ברשת ה-VPC.
  • אם הכללים חסרים, אפשר ליצור אותם מחדש באופן ידני או למחוק את משאב ה-Ingress וליצור אותו מחדש כדי להפעיל את היצירה האוטומטית שלהם.
  • חשוב לוודא שכללי חומת האש מאפשרים תעבורה ביציאות ובפרוטוקולים המתאימים, כפי שמוגדר במשאב Ingress.

נעשה שימוש בפרוטוקול שגוי במניפסט BackendConfig

אם מגדירים BackendConfig CRD עם פרוטוקול מסוג TCP, מוצגת השגיאה הבאה:

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

‫BackendConfig תומך ביצירת בדיקות תקינות באמצעות הפרוטוקולים HTTP,‏ HTTPS או HTTP/2 בלבד. מידע נוסף אפשר למצוא במאמר בנושא קריטריונים להצלחה של HTTP,‏ HTTPS ו-HTTP/2.

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