Istio ו-Kubernetes בהפקה. חלק 2. מעקב

בעבר статье בדקנו את המרכיבים הבסיסיים של Service Mesh Istio, הכרנו את המערכת וענינו על השאלות העיקריות שעולות בדרך כלל כאשר מתחילים לעבוד עם Istio. בחלק זה נבחן כיצד לארגן את איסוף מידע המעקב על גבי רשת.

הדבר הראשון שעולה לראש עבור מפתחים ומנהלי מערכות רבים כשהם שומעים את המילים Service Mesh is tracing. ואכן, אנו מוסיפים שרת פרוקסי מיוחד לכל צומת רשת שדרכו עוברת כל תעבורת ה-TCP. נראה כי כעת ניתן לשלוח בקלות מידע על כל אינטראקציות הרשת ברשת. למרבה הצער, במציאות יש הרבה ניואנסים שצריך לקחת בחשבון. בואו נסתכל עליהם.

תפיסה מוטעית מספר אחת: אנחנו יכולים לקבל נתוני טיולים מקוונים בחינם.

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

ראשית, בואו נסתכל כיצד נראית טווחי מעקב של שליחת מנקודת מבט אדריכלית באיסטיו. כזכור מהחלק הראשון, לאיסטיו יש רכיב נפרד בשם Mixer לאיסוף טלמטריה. עם זאת, בגרסה הנוכחית 1.0.*, השליחה מתבצעת ישירות משרתי פרוקסי, דהיינו, משרת proxy של שליח. Proxy של Envoy תומך בשליחת טווחי מעקב באמצעות פרוטוקול zipkin מחוץ לקופסה. אפשר לחבר פרוטוקולים אחרים, אבל רק באמצעות תוסף. עם Istio אנחנו מקבלים מיד פרוקסי של שליחים מורכב ומוגדר, שתומך רק בפרוטוקול zipkin. אם אנחנו רוצים להשתמש, למשל, בפרוטוקול Jaeger ולשלוח טווחי מעקב דרך UDP, אז נצטרך לבנות תמונת istio-proxy משלנו. יש תמיכה בתוספים מותאמים אישית עבור istio-proxy, אבל זה עדיין בגרסת האלפא. לכן, אם ברצוננו להסתדר ללא מספר רב של הגדרות מותאמות אישית, מגוון הטכנולוגיות המשמשות לאחסון וקבלת טווחי מעקב מצטמצם. מהמערכות העיקריות, למעשה, עכשיו אתה יכול להשתמש ב-Zipkin עצמה, או ב-Jaeger, אבל לשלוח לשם הכל באמצעות פרוטוקול תואם zipkin (שהוא הרבה פחות יעיל). פרוטוקול zipkin עצמו כולל שליחת כל מידע המעקב לאספנים באמצעות פרוטוקול ה-HTTP, שהוא די יקר.

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

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

אתה יכול גם להשתמש בשמות מורכבים כמו http-magic (Istio יראה http ויזהה את היציאה הזו כנקודת קצה http). הפורמט הוא: פרוטו-אקסטרה.

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

על מנת להבין האם הפרוטוקול באמת מוגדר נכון, עליכם להיכנס לכל אחד ממיכלי ה-sidecar עם proxy של envoy ולבצע בקשה לפורט המנהל של ממשק ה-envoy עם location /config_dump. בתצורה המתקבלת, עליך להסתכל על שדה הפעולה של השירות הרצוי. הוא משמש ב-Istio כמזהה למקום שבו מוגשת הבקשה. על מנת להתאים אישית את הערך של פרמטר זה ב-Istio (לאחר מכן נראה אותו במערכת המעקב שלנו), יש צורך לציין את דגל serviceCluster בשלב השקת מיכל ה-sidecar. לדוגמה, ניתן לחשב אותו כך ממשתנים המתקבלים מהממשק ה-API של kubernetes כלפי מטה:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

דוגמה טובה להבין איך המעקב עובד ב-envoy היא כאן.

יש לציין גם את נקודת הקצה עצמה לשליחת טווחי מעקב בדגלי ההשקה של ה-proxy של השליח, לדוגמה: --zipkinAddress tracing-collector.tracing:9411

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

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

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

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sampled,
• x-b3-flags,
• x-ot-span-context.

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

מסקנה

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

במאמר הבא על Service Mesh, נבחן את אחת הבעיות הגדולות ביותר עם Istio - הצריכה הגדולה של זיכרון RAM על ידי כל מיכל Proxy Sidecar ונדון כיצד תוכל להתמודד איתה.

מקור: www.habr.com