פתרון בעיות שקשורות לניהול תעבורה ב-Cloud Service Mesh

בקטע הזה מוסבר על בעיות נפוצות ב-Cloud Service Mesh ואיך לפתור אותן. לקבלת עזרה נוספת, אפשר לעיין במאמר בנושא קבלת תמיכה.

שגיאות בחיבור לשרת API ביומני Istiod

אם מופיעות שגיאות דומות לשגיאות הבאות, יכול להיות ש-Istiod לא יכול ליצור קשר עם apiserver:

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

אפשר להשתמש במחרוזת הביטוי הרגולרי /error.*cannot list resource/ כדי למצוא את השגיאה הזו ביומנים.

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

קריסה של מאגר התגים istio-init

הבעיה הזו יכולה לקרות כשכללי ה-iptables של ה-pod לא מוחלים על מרחב השמות של רשת ה-pod. הסיבות האפשריות לכך:

  • התקנה לא מלאה של istio-cni
  • הרשאות לא מספיקות של פוד בעומס עבודה (חסרה הרשאה CAP_NET_ADMIN)

אם אתם משתמשים בתוסף Istio CNI, ודאו שפעלתם לפי כל ההוראות. מוודאים שהמאגר istio-cni-node מוכן ובודקים את היומנים. אם הבעיה נמשכת, צריך ליצור מעטפת מאובטחת (SSH) בצומת המארח ולחפש ביומני הצומת פקודות nsenter כדי לבדוק אם יש שגיאות.

אם אתם לא משתמשים בפלאגין Istio CNI, אתם צריכים לוודא שלפוד של עומס העבודה יש הרשאה CAP_NET_ADMIN, שמוגדרת באופן אוטומטי על ידי sidecar injector.

החיבור נדחה אחרי שה-pod מתחיל

כש-Pod מתחיל ומקבל connection refused ניסיון להתחבר לנקודת קצה, יכול להיות שהבעיה היא שמאגר האפליקציות התחיל לפני מאגר isto-proxy. במקרה הזה, קונטיינר האפליקציה שולח את הבקשה אל istio-proxy, אבל החיבור נדחה כי istio-proxy עדיין לא מאזין ליציאה.

במקרה כזה, אפשר:

  • משנים את קוד ההפעלה של האפליקציה כך שישלח בקשות חוזרות לנקודת הקצה של istio-proxy הבדיקה עד שהאפליקציה תקבל קוד 200. נקודת הקצה (endpoint) של התקינות istio-proxy היא:

    http://localhost:15020/healthz/ready

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

הפונקציה Listing gateways מחזירה ערך ריק

הסימפטום: כשמריצים את הפקודה kubectl get gateway --all-namespaces כדי להציג רשימה של שערים אחרי שיוצרים שער Cloud Service Mesh, הפקודה מחזירה את הערך No resources found.

הבעיה הזו יכולה לקרות ב-GKE 1.20 ובגרסאות מתקדמות יותר, כי בקר GKE Gateway מתקין אוטומטית את משאב GKE Gateway.networking.x-k8s.io/v1alpha1 באשכולות. כדי לעקוף את הבעיה:

  1. בודקים אם יש כמה משאבים מותאמים אישית של שער באשכול:

    kubectl api-resources | grep gateway

    פלט לדוגמה: 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. אם ברשימה מופיעים ערכים אחרים מלבד Gateways עם apiVersion networking.istio.io/v1beta1, צריך להשתמש בשם המשאב המלא או בשמות המקוצרים הייחודיים בפקודה kubectl. לדוגמה, מריצים את הפקודה kubectl get gw או kubectl get gateways.networking.istio.io במקום kubectl get gateway כדי לוודא שרכיבי ה-Gateway של Istio מופיעים.

מידע נוסף על הבעיה הזו זמין במאמר בנושא Kubernetes Gateways and Istio Gateways.