פתרון בעיות שקשורות למגבלות משאבים ב-Cloud Service Mesh

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

בעיות במגבלות המשאבים של Cloud Service Mesh יכולות להיגרם מכל אחת מהסיבות הבאות:

אובייקטים של LimitRange שנוצרו במרחב השמות istio-system או בכל מרחב שמות אחר שבו מופעלת הזרקה אוטומטית של קובצי sidecar.
מגבלות שהוגדרו על ידי המשתמש והן נמוכות מדי.
הזיכרון או משאבים אחרים של הצמתים אזלו.

תסמינים אפשריים של בעיות במשאבים:

‫Cloud Service Mesh לא מקבל שוב ושוב הגדרות ממישור הבקרה, כפי שמצוין בשגיאה Envoy proxy NOT ready. השגיאה הזו יכולה להופיע כמה פעמים בזמן ההפעלה, אבל אם היא מופיעה בזמנים אחרים, זה כבר בעייתי.
בעיות ברשת עם פודים או צמתים מסוימים שלא ניתן להגיע אליהם.
‫istioctl proxy-status showing STALE statuses in the output.
הודעות OOMKilled ביומנים של צומת.
השימוש בזיכרון לפי מאגרים: kubectl top pod POD_NAME --containers.
השימוש בזיכרון על ידי פודים בתוך צומת: kubectl top node my-node.
‫Envoy out of memory: kubectl get pods shows status OOMKilled in the output.

עובר זמן רב עד ש-Sidecars מקבלים את ההגדרה

התפשטות איטית של ההגדרה יכולה לקרות בגלל הקצאה לא מספקת של משאבים ל-istiod או בגלל גודל גדול מדי של האשכול.

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

ב-Cloud Service Mesh בתוך האשכול, אם כלי המעקב שלכם (prometheus,‏ stackdriver וכו') מראים ניצול גבוה של משאב על ידי istiod, כדאי להגדיל את ההקצאה של המשאב הזה. לדוגמה, אפשר להגדיל את מגבלת ה-CPU או הזיכרון של הפריסה של istiod. זהו פתרון זמני, ואנחנו ממליצים לבדוק שיטות להפחתת צריכת המשאבים.
אם הבעיה הזו מתרחשת באשכול גדול או בפריסה גדולה, צריך לצמצם את כמות מצב ההגדרה שמועברת לכל שרת proxy על ידי הגדרת משאבי Sidecar.
ב-Cloud Service Mesh בתוך האשכול, אם הבעיה נמשכת, כדאי לנסות לבצע הרחבה אופקית istiod.
אם כל השלבים האחרים לפתרון בעיות לא פותרים את הבעיה, צריך לדווח על באג ולפרט את הפריסה ואת הבעיות שנצפו. אם אפשר, כדאי לכלול בדוח הבאג פרופיל של CPU/זיכרון, וגם תיאור מפורט של גודל האשכול, מספר ה-Pods ומספר השירותים. כדי לעשות את זה, פועלים לפי השלבים האלה.