353 Istio

פודקאסט מספר 353 של רברס עם פלטפורמה - אורי ורן מארחים במוצאי חג הבחירות המוניציפליות את שי ארליכמן לשיחה על פרויקט Istio (תזכורת לפודקאסט 351 / באמפרס 52). שי הוא CTO ומייסד משותף (Co-founder) של missinglink, שמספקת פלטפורמה לחברות עם Stack של למידה עמוקה (Deep Learning) ולמידת מכונה (Machine Learning), ועוזרת להן לנהל את הפיתוח והמידע - כלים שהתרגלנו אליהם בעולם קוד המקור ועדיין פחות נפוצים בתחומים הללו. החברה גדלה וכבר יש לקוחות משלמים, המוצר מפותח כבר שנתיים (ומשוחרר לשוק כמעט מההתחלה), הלקוחות הם המפתחים (קהל מאתגר :-)). חלק מ-Samsung Next, ממוקמים בשרונה בתל אביב (!Sharona  - לא להסתבך עם אבשלום קור). אז מה זה Istio? מפרש ביוונית. מתכתב עם ההגה של Kubernetes. יהיו עוד רפרנסים לים בהמשך . . . אז מה הבעיה? בפיתוח אפליקציות Web עולה השאלה של מה עושים ב-Production? הפתרון היה nginx לפני האפלקציה, שהיה משרת ודואג ללוגים, Load Balancing וכו’ (גם Caching, אם כי זה בדרך כלל בעצם Varnish ברקע). ואז הגיע Docker, וניהיה מאוד קל לעשות Deploy. ועדיין - היה Load Balancer לפני האפליקציה (אותו nginx). ואז יצא Kubernetes כדי לנהל את הכל. אז מי מנהל את ה-Load Balancer? כאן הגענו ל-Istio. מדובר קודם כל בסט כלים (שאמור להיות אדיש לפלטפורמה - Platform-Agnostic - אבל עובד הכי טוב מעל Kubernetes), שיוצר מעיין תווך בכל נקודה, ו”משתלט” על כל נקודות הקצה. כל בקשה (Request) מגיעה כל קודם אליו, ובעזרת מדיניות (Policy) מוגדרת הוא מחליט מה לעשות הלאה. דוגמא - משתמשים עם Cookie מסוג מסויים יופנו לגרסת Canary מסויימת, והיתר לגרסה שונה. אין צורך בשני שרתים או שתי סביבות וכו’. המודל הוא Layer 7 Routing - מודל OCI, שמאפשר להוסיף מאפיינים ''חכמים'', לא רק Routing אלא גם Logging (כי הוא מכיר את כל נקודות הקצה ויכול לייצר תשתית Tracing). שירותי Load Balancing קיימים במגוון צורות (HAProxy ושלל כלים של רוב ספקי הענן העיקריים - ELB, ALB, GCLB וכו’). מה שייחודי ב-Istio זה המימוש המבוזר. לא מרימים אף מכונה - רצים רק איפה שהשירות (Service) רץ, וה-Proxy נעשה בצורה שקופה. באותם Dockers (ה-Pods) של ה-Services הרלוונטיים יש נציג (Agent) של Istio: ה-Sidecar (סירה. של אופנוע, ועדיין עוד רפרנס לים). זהו אותו Proxy של Envoy שפותח ב-Lyft. לא ברור למה היה צריך עוד אחד מחדש, אבל נראה שיש להם את המשאבים ובכל מקרה יצא פרויקט מדהים. Istio הוא בעצם הרחבה (Extension) של Envoy. העבודה עם Kubernetes מאוד צמודה - בגרסא 1.9 למשל נוסף Webhook Injection, שתופס את כל ה-Events שמתרחשים, ויודע להיכנס בדיוק לנקודות שצריך להתממשק בהן. זהו מעיין End-point שמחצין את עצמו, ויש מאחוריו Service Discovery שימצא את השירות (Service) הנכון שאליו אני רוצה להגיע. קצת כמו Venom.  ניתן להקביל את זה ל-Proxy מאוד חכם שעוטף, יודע לזהות את ה-End Point, מבין לאן הייתה הכוונה לפנות, ומודע לעצם הקריאה. דוגמא - פנייה לשירות שנותן את זמני הזריחה והשקיעה (עינייני בית חכם), שנחסמה כיוון שלא ניתנה הרשאה ל-Istio לפנות לאותו שירות חיצוני - מעבר להשתלטות על הקלט, יש כאן גם ''הבנה'' (הסקה) עמוקה יותר לגבי הפלט הצפוי.  לא מדובר על החלפה של שירותי ה-Routing, אלא מעיין ניטור שלהם. שרשרת הקריאות נשמרת וניתן לנתח אותה ולהסיק על ההתנהגות של ה-Service Mesh. סיכום ביניים - Istio מאפשר שלושה שירותים של ראוטר מתוחכם: ניתוב חכם (Smart routing). אבטחת מידע (Security) - גורם לכל השירותים להיות MTLS. לוגים (ו-Tracing). כרגע לא על הכל לגמרי אבל זה הכיוון. טלמטריה, לרמה של E2E Tracing (עם מזהה לקריאה ספציפית) - שליטה על כל שרשרת הקריאות (מי הניע את מי), כשיש כלים כמו Zipkin ו-Prometheus שמאפשרים לראות מעיין “מפל” של שרשרת האירועים שנגרמו מקריאה מסויימת. מכאן אפשר לנתח כל מיני דברים, כמו זמן ממוצע למשך קריאה בהשוואה להתפלגות משך הקריאות הכללית וכו’. וכל זה אמור להתבצע אוטומטית. ב-Prometheus (גרסא 1.02) יש כבר הכל בפנים, והתחלה של גרף קריאות. לפחות חלק מהצוות שעובד על המוצר נמצא כאן בישראל במעבדות IBM בחיפה. הפרויקט בגדול נולד כשיתוף פעולה של IBM ו-Google, איפה זה נמצא היום? הבעיה (או “האתגר” בניסוח יותר אופטימי) היא שהפרויקט אמור לתמוך “בהכל”. בדומה ל-Kubernetes שהיה צריך את ה-EKS וה-Kubernetes Engine כדי להוריד את רמת הקושי, זה עדיין לא שם. צריך לקרוא הרבה מדריכים (ולהבין מה רלוונטי). זה עדיין שווה את זה. כיום, Kubernetes מאפשר רמה מסויימת של Routing ו-Load Balancing בין ה-Pods השונים באמצעות אבסטרקציה של Service. הבעיה היא שזה מאוד מוגבל מבחינת פתרון “חכם” ומצריך Plug-Ins שונים (ל-Security למשל), לא מובן מאליו בגרסת Out of the box, אם בכלל. אפשר לומר ש-Istio מחליף את שכבת ה-Load Balancing של Kubernetes, ומוסיף על זה את האלמנטים שהוזכרו למעלה. למה זה כל כך מסובך אם הכל זה רק Sidecar? יש כאן מעבר להתקנה של Docker לצד Docker . . .  ל-Istio יש ארבעה רכיבים עיקריים -  מיקסר (Mixer), שתפקידו לקחת את המדיניות (Policy) ו”לערבב” לתוך ה-Sidecar. פיילוט (Pilot), שתפקידו לבצע את ה-Routing. יש את ה-Citadel (למעריצי Rick and Morty), שתפקידו לנהל הרשאות (Certifications), באופן בלתי תלוי במה שרץ מתחת (Kubernetes, Mesos או משהו אחר) שכבה של Auto-injection, שתופסת את מה שקורה ב-Cluster על מנת לקבל החלטות. למה זה כל כך הסתבך? כי זה עולם גדול, עם הרבה צרכים והרבה אפשרויות שצריך לכסות, ואנחנו רק בגרסא ראשונה. זו רק ההתחלה. מתי אני יודע שאני צריך Istio? שי אומר שאם אתם משתמשים ב-Kubernetes, אתם צריכים Istio. כנסו לאתר של Zipkin ותראו את רמת ה-Tracing. תבינו שאתם טסים בלי מכשירים ותרצו גם כזה.  בעולם של App Engine היה Tracing Built-in - אתה רואה את הכל וכמה כל דבר לוקח. אתה מתרגל, ואז אתה מצפה לזה בכל מקום. אז Istio. ובכל זאת - מה לגבי Security? נשאלת השאלה האם יש צורך שתקשורת בין Services תיהיה ברמת אבטחה מקסימלית (ומה המחיר)? שי אומר שאצלו רוב המידע מועבר בתוך ה-Private Network אז זה פחות חושב - וזה חינם. האם רכיבי Istio בעננים שונים יודעים לתקשר אחד עם השני? על הנייר כן, ויש MTLS out of the Box. האם זה עובד באמת? שי לא ניסה, אבל זה אמור לעבוד (וזה גם שם של דג, כי חייבים עוד רפרנס אחרון לים). עוד פיצ’ר מעניין (אם כי עלול להיות מעט מסוכן) הוא Retry לקריאה שנכשלה (למשל Outbound Call) - אפשר להגדיר Policy שתנסה שוב מספר מוגדר של פעמים, וזה לא חלק מהקוד אלא חלק מה- Policy. זה הרבה יותר נוח (לא צריך לממש את הלוגיקה). כשחושבים על זה, Istio נמצא בכל מקום והכל עובר דרכו - זה לא יוצר עוד Latency? כן, זה מוסיף. צריך למדוד את זה. מישהו התלונן שעבור 2000 שירותים, ה-Sidecar מגיע ל-8G צריכת זכרון (יש גם בפחות) . . . עובדים על זה. בכאלה מספרים של שירותים יש כנראה עוד כמה בעיות מעבר ל-Sidecar. זה מעלה משמעותית את התקורה ההתחלתית של פרויקט. שימושי יותר עבור פרויקטים בשלבים מתקדמים יותר שרוצים לגדול (או מתכננים קדימה). המימוש של Envoy מאוד יעיל, כך שהחזקה של כל מפת הקריאות היא לא בהכרח בעיה ברוב המקרים אבל שוב - צריך למדוד. היום כבר לא צריך לחשוב על התווך, ולדאוג האם קריאת ה-HTTP יצאה ומה לגבי ה-MTU - צריך לכתוב את הקוד, והשכבות למטה יסתדרו באופן היעיל ביותר. האם Retry למשל לא כבר נמצא בתוך GRPC? לא, וכנראה שבכוונה. שימוש ב-Retry הוא סוג של פלסתר, שעלול ליצור Latency שיצטבר בלי לשים לב. כאן נכנס ה-Tracing שאמור להציף את זה. לסיכום - אם אתם משתמשים ב-Kubernetes, תנו מבט על Istio, אתם כראה צריכים כזה. תבדקו. הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול