פתרון בעיות שקשורות לשינוי קנה מידה של Istiod ב-Cloud Service Mesh
בקטע הזה מוסבר על בעיות נפוצות ב-Cloud Service Mesh ואיך לפתור אותן. לקבלת עזרה נוספת, אפשר לעיין במאמר בנושא קבלת תמיכה.
גורמים לקביעת קנה מידה
Istiod שולח את ההגדרה לכל sidecar באמצעות זרם gRPC לטווח ארוך. יש לו כמה מאפיינים שמשפיעים על ההתאמה לגודל:
- הגודל של ההגדרות שרוצים ליצור:
- המספר הכולל של שירותים/pods ומשאבי Istio
- בפריסה בקנה מידה גדול, צריך לשנות את ההגדרות של Sidecar כדי להקטין את גודל ההגדרה.
- קצב השינוי בסביבה:
- כשיוצרים שירות חדש או משנים את ההגדרה של Istio, מתבצעים עדכונים מלאים לפרוקסי.
- הוספה של נקודות קצה חדשות לא פוגעת בביצועים, כי נשלחים רק עדכונים מצטברים.
- מספר שרתי ה-proxy שעבורם נוצרת ההגדרה:
- מושפע ממספר השערים והפודים עם sidecar.
שיקולים לגבי התאמה להיקף
הסקלביליות של Istiod טובה גם אנכית (בקשות גדולות) וגם אופקית (יותר רפליקות). חשוב לוודא שמגבלות ה-CPU לא מגבילות מדי. אם Istiod יגיע למגבלת ה-CPU, יכול להיות שיתרחש ויסות שישפיע לרעה על הפצת ההגדרות. אם נתקלתם בבעיות בביצועים, כדאי לשדרג לגרסה האחרונה של Cloud Service Mesh, כי בכל גרסה יש שיפורים בביצועים.
עומס לא מאוזן
שינויים גדולים בגודל האשכול עלולים לגרום לעומס לא מאוזן באופן זמני, בגלל
החיבורים ארוכי הטווח. הבעיה הזו נפתרת על ידי הגבלת משך החיבור ל-30 דקות, מה שעשוי לגרום להודעות שגיאה ב-Envoy, כמו gRPC config stream
closed: 13, וכך העומס מתאזן מחדש באופן טבעי.
כדי לצמצם את הבעיה הזו, כדאי ליצור כמה עותקים של Istiod (ברירת המחדל היא 2 עותקים) ולבצע קדם-התאמה אם צפויים גידולים קיצוניים בגודל האשכול.