Istio Circuit Breaker: השבתת מיכלים פגומים

החגים הסתיימו וחזרנו עם הפוסט השני שלנו בסדרת Istio Service Mesh.

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

איך זה אמור לעבוד באופן אידיאלי

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

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

איך זה באמת עובד

עכשיו תארו לעצמכם שמופע ספציפי של מיקרו-שירות, כלומר מיכל, הפך לבלתי שמיש: או שהוא לא מגיב (שגיאה 503), או, מה שלא נעים יותר, הוא מגיב, אבל לאט מדי. במילים אחרות, הוא הופך לקוי או לא מגיב לבקשות, אבל הוא לא מוסר אוטומטית מהבריכה. מה צריך לעשות במקרה זה? לנסות שוב? האם עלי להסיר אותו מסכימת הניתוב? ומה זאת אומרת "איטי מדי" - כמה זה במספרים, ומי קובע אותם? אולי פשוט תתנו לזה הפסקה ותנסו שוב מאוחר יותר? אם כן, כמה מאוחר יותר?

מהי פליטת בריכה באיסטיו

וכאן Istio באה לעזרה עם מכונות הגנת ה-Circuit Breaker שלה, אשר מסירות באופן זמני מכלים פגומים ממאגר המשאבים של ניתוב ואיזון עומסים, תוך יישום הליך פליטת הבריכה.

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

כדי להראות איך זה עובד ב-Kubernetes בפלטפורמת OpenShift, נתחיל בצילום מסך של מיקרו-שירותים שפועלים בדרך כלל מהדוגמה במאגר הדגמות למפתחים של Red Hat. כאן יש לנו שני פודים, v1 ו-v2, שכל אחד מהם מפעיל מיכל אחד. כאשר לא נעשה שימוש בכללי ניתוב של Istio, Kubernetes משתמש כברירת מחדל לניתוב עגול מאוזן באופן שווה:

מתכוננים לכישלון

לפני ביצוע הוצאת בריכה, עליך ליצור כלל ניתוב של Istio. נניח שאנו רוצים לחלק בקשות בין תרמילים ביחס של 50/50. בנוסף, נגדיל את מספר הקונטיינרים של v2 מאחד לשני, כך:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

כעת אנו מגדירים כלל ניתוב כך שהתעבורה תתחלק בין תרמילים ביחס של 50/50.

כך נראית התוצאה של כלל זה:

אפשר למצוא פגם בכך שהמסך הזה הוא לא 50/50, אלא 14:9, אבל עם הזמן המצב ישתפר.

עושה תקלה

עכשיו בואו נשבית את אחד משני מיכלי v2 כך שיהיה לנו מיכל v1 בריא אחד, מיכל v2 בריא ומיכל v2 פגום אחד:

תיקון התקלה

אז, יש לנו מיכל פגום, והגיע הזמן לפליטת בריכה. באמצעות תצורה פשוטה מאוד, נוציא את המיכל הכושל הזה מכל סכימות ניתוב למשך 15 שניות בתקווה שהוא יחזור למצב בריא (או הפעלה מחדש או שחזור ביצועים). כך נראית התצורה הזו והתוצאות של עבודתה:

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

בואו נתחיל לבנות אדריכלות

פליטת הבריכה, בשילוב עם יכולות הניטור של Istio, מאפשרת לך להתחיל בבניית מסגרת להחלפה אוטומטית של מיכלים פגומים כדי לצמצם, אם לא לבטל, זמן השבתה ותקלות.
 
לנאס"א יש מוטו רם אחד - כישלון אינו אופציה, שמחברו נחשב למנהל הטיסה ג'ין קרנץ. אפשר לתרגם את זה לרוסית כ"כישלון הוא לא אופציה", והכוונה כאן היא שאפשר לגרום להכל לעבוד אם יש לך מספיק רצון. עם זאת, בחיים האמיתיים, כישלונות לא קורים סתם, הם בלתי נמנעים, בכל מקום ובכל דבר. ואיך להתמודד איתם במקרה של שירותי מיקרו? לדעתנו, עדיף להסתמך לא על כוח רצון, אלא על יכולות של מכולות, קוברנט, רד האטו - Istio.

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

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

מפסק מעגל בתיאוריה

Circuit Breaker הוא פרוקסי השולט בזרימת הבקשות לנקודת קצה. כאשר נקודה זו מפסיקה לעבוד או, בהתאם להגדרות שצוינו, מתחילה להאט, ה-proxy מנתק את הקשר עם הקונטיינר. לאחר מכן התנועה מנותבת למכולות אחרות, פשוט עקב איזון עומסים. החיבור נשאר פתוח למשך חלון שינה נתון, נניח שתי דקות, ואז נחשב לחצי פתוח. ניסיון לשלוח את הבקשה הבאה קובע את מצב החיבור הנוסף. אם הכל תקין בשירות, החיבור חוזר למצב תקין ושוב נסגר. אם עדיין משהו לא בסדר בשירות, החיבור מנותק וחלון השינה מופעל מחדש. כך נראה דיאגרמת מצב מפסק מעגלים פשוטה:

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

מפסק מעגל בפועל

לדוגמה, נריץ שתי גרסאות של מיקרו-שירות ההמלצה שלנו ב-OpenShift. גרסה 1 תעבוד בסדר, אבל ב-v2 נבנה השהייה כדי לדמות האטות בשרת. כדי לראות את התוצאות, השתמש בכלי מצור:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

נראה שהכל עובד, אבל באיזה מחיר? במבט ראשון, יש לנו 100% זמינות, אבל תסתכל מקרוב - משך העסקה המקסימלי הוא עד 12 שניות. ברור שזה צוואר בקבוק וצריך להרחיב אותו.

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

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

בסדר, יש לנו מפסק, מה הלאה?

אז, הטמענו כיבוי אוטומטי מבלי לגעת כלל בקוד המקור של השירותים עצמם. באמצעות Circuit Breaker והליך פליטת הבריכה המתואר לעיל, נוכל להסיר מכלי בלמים ממאגר המשאבים עד שהם יחזרו לקדמותם, ולבדוק את מצבם בתדירות מוגדרת - בדוגמה שלנו, מדובר בשתי דקות (פרמטר sleepWindow).

שים לב שהיכולת של יישום להגיב לשגיאת 503 עדיין מוגדרת ברמת קוד המקור. ישנן אסטרטגיות רבות לשימוש ב-Circuit Breaker, בהתאם למצב.

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

מקור: www.habr.com