פתרון בעיות שקשורות ל-sidecar proxy או ל-webhook ב-Cloud Service Mesh

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

‫Cloud Service Mesh כולל שני ווּבְּהוּקים:

  • התגובה לפעולה מאתר אחר (Webhook) שמתבצעת לצורך אימות, מוודאת שההגדרה של Istio שחלה על המערכת היא תקינה.
  • ה-webhook לשינוי מגדיר הזרקה אוטומטית של sidecar לפודים חדשים.

בעיה בהגדרה של אחד מה-webhook האלה עלולה לגרום לכך שפודים חדשים לא יופעלו או שיוצגו הודעות שגיאה.kubectl apply

בעיות בהחדרת Sidecar

אם הקציתם משאבים של Cloud Service Mesh מנוהל, פנו לתמיכה.

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

  • pods that are scheduling without sidecars
  • ‫pods שאמורים להיות מוזרקים ל-sidecars אף פעם לא מופיעים כשמשתמשים ב-kubectl get pods, אבל קבוצת העותקים התואמת מ-kubectl get replicaset קיימת.

כדי לפתור בעיות בהחדרת sidecar, אפשר להיעזר בשלבים הבאים.

  1. מוודאים שלמרחב השמות או ל-Pod יש תווית הזרקה נכונה.

    אם אתם מפעילים Istio עם עדכון יחיד (ברירת המחדל), צריך לוודא שלמרחב השמות או למפרט הפוד יש את התווית istio-injection=enabled.

    אם אתם מפעילים כמה גרסאות של Istio (לצורך העברות ללא השבתה, כמה מישורי בקרה וכו'), צריך לוודא שלמרחב השמות או למפרט הפוד יש את התווית המתאימה istio.io/rev=REVISION, כאשר REVISION הוא מספר הגרסה של Cloud Service Mesh ב-istiod שתואם לגרסה שבחרתם של Cloud Service Mesh. מידע נוסף על תוויות של עדכונים זמין במאמר הוספת פרוקסי מסוג sidecar.

  2. מוודאים שרכיב ה-webhook להזרקת sidecar של istio קיים וכולל חבילת אישורים.

    תגובת ה-webhook של מנגנון הזרקת ה-sidecar (שמשמשת להזרקת sidecar אוטומטית) דורשת חבילת CA כדי ליצור חיבורים מאובטחים עם שרת ה-API ועם istiod. חבילת אישורי ה-CA הזו מוטמעת בהגדרה על ידי istiod, אבל לפעמים היא יכולה להידרס (לדוגמה, אם מפעילים מחדש את ההגדרה של ה-webhook).

    אפשר לוודא שחבילת אישורי ה-CA קיימת באמצעות הפקודה הבאה. הפקודה כוללת את istio-sidecar-injector-asm-1246-12, שספציפית לגרסה הזו של Cloud Service Mesh. חשוב לוודא שאתם משתמשים בגרסה בפועל אם היא שונה.

    kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1246-12 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'

    אם הפלט לא ריק, חבילת אישורי ה-CA מוגדרת. אם חבילת רשות האישורים חסרה, מפעילים מחדש את istiod כדי שהמערכת תסרוק מחדש את ה-webhook ותתקין מחדש את חבילת רשות האישורים.

  3. בודקים אם יש כשלים בהזרקה של sidecar.

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

    kubectl -n my-namespace describe replicaset your-deployment-name

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

  4. אם הבעיה נמשכת, יכול להיות שהיא נובעת מאחת מהסיבות הבאות:

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

    כאן מפורטים שלבים נוספים לאבחון בעיות ב-Istio.

שרתי proxy של Envoy לא מקבלים הגדרה מ-istiod

יש כמה בעיות שיכולות למנוע משרתי proxy לקבל הגדרה מ-istiod.

  1. ‫istiod לא ידחוף את ההגדרה לשרתי ה-proxy של Envoy אם יש לו בעיות, כמו בעיה ב-RBAC שמונעת ממנו לקרוא את משאב ההגדרה שלו.

  2. כתובת Discovery שגויה (שגיאות 'no healthy upstream')

  3. הכתובת של ה-Discovery שסופקה למנגנון הזרקת ה-sidecar שגויה. אם רואים יומנים שבהם מוזכרת gRPC config stream closed, no healthy upstream, צריך לוודא שכתובת הגילוי ברשת ProxyConfig נכונה ומפנה לשירות istiod.

  4. הגדרות לא תקינות נדחפות לשרת ה-Proxy. במקרה הזה, ההגדרה נדחפת ל-Proxy בהצלחה, אבל ההגדרה לא תקינה. יופיעו הודעות חוזרות שדומות להודעות הבאות:

    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected

    בדוגמה הזו, cds הוא Cluster Discovery Service (שמדווח על עדכון אחד שנשלח מ-istiod), ו-lds הוא Listener Discovery Service (שמדווח על עדכון אחד שנדחה מ-istiod). לעיתים קרובות תופיע הודעת שגיאה מוקדמת יותר שמסבירה את הסיבה לדחייה, שבדרך כלל מתחילה באזהרה לגבי הגדרת envoy או משהו דומה.

    כדי לפתור את הבעיה, צריך לבדוק מה גרם לדחיית ההגדרה. אחת הסיבות הנפוצות היא משאבי EnvoyFilter לא תקינים. אם הסיבה לא ברורה, שולחים דוח באגים עם dump של הגדרות ה-proxy.

יצירת ה-Pod נכשלת

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

kubectl describe replicaset YOUR_REPLICA_SET

הודעות שגיאה נפוצות ב-webhook

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

הודעת השגיאה הסיבה הפתרון
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) יכול להיות שזו בעיה בחיבור לרשת. מוודאים שכללי חומת האש מספקים קישוריות ל-`istiod` ביציאה 15017.
no endpoints available for service 'istiod' הבעיה יכולה לקרות אם הפוד `istiod` לא זמין או לא מוכן. בודקים את הפודים של ‎ `istiod` ‎ כדי לוודא שהם פועלים ומוכנים.
Service "istiod" not found הבעיה הזו יכולה לקרות אם השירות `istiod` לא קיים. מוודאים שההתקנה של Istio בוצעה בהצלחה ובצורה נכונה.
x509: certificate signed by unknown authority יכול להיות שזו בעיה באישור של ה-webhook. בודקים שהערך caBundle מוגדר בצורה נכונה ב-webhook.
Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again. יכול להיות ש-webhook לאימות מגרסה ישנה של Istio או של Cloud Service Mesh שהוסרה מפריע לשדרוג או להתקנה. בודקים שכל ה-webhook עדיין באשכול ומסירים את ה-webhook(s) שמפנים לגרסאות שכבר לא מותקנות.
Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded במקרה של אשכולות פרטיים, צריך לפתוח את יציאה 15017. הודעת השגיאה הזו מציינת שאולי יציאה 15017 לא פתוחה. מוודאים שכללי חומת האש מספקים קישוריות ל-Istiod ביציאה 15017. מידע נוסף זמין במאמר בנושא פתיחת פורט באשכול פרטי.