🥇חזרה לשירותי מיקרו עם Istio. חלק 1

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

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

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

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

מנהל פרויקט: כמה זמן לוקח להוסיף תכונת משוב?
מפתח: שני ספרינטים.

MP: מה?... זה פשוט CRUD!
R: ביצוע CRUD הוא החלק הקל במשימה, אבל אנחנו עדיין צריכים לאמת ולאשר משתמשים ושירותים. מכיוון שהרשת אינה אמינה, תצטרך ליישם בקשות חוזרות, כמו גם דפוס מפסק בלקוחות. כמו כן, כדי לוודא שכל המערכת לא קרסה, פסקי זמן ו מחיצות (ראה בהמשך המאמר לפרטים נוספים על שני הדפוסים שהוזכרו.), ועל מנת לאתר בעיות, ניטור, מעקב, […]
MP: אה, אז בוא נכניס את התכונה הזו לשירות המוצר.

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

שים לב: המאמר מניח שיש לך ידע בעבודה עם Kubernetes. אחרת, אני ממליץ לקרוא ההיכרות שלי עם Kubernetes ורק אז להמשיך לקרוא את החומר הזה.

רעיון איסטיו

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

תעבורת רשת ב-Kubernetes

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

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

אלו הן רק כמה מהאפשרויות (באמת רק כמה!) לסקרן אותך. עכשיו בואו נצלול לפרטים הטכניים!

ארכיטקטורה

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

מטוס נתונים

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

כיצד ניסיונות חוזרים ושבירת מעגלים מיושמים ב-Envoy

סיכום:

שַׁגְרִיר (אנחנו מדברים על פרוקסי הממוקם במיכל צדדי, שמופץ כ מוצר נפרד - משוער. תרגום) שולח בקשה למופע הראשון של שירות B ונכשל.
Envoy Sidecar מנסה שוב (נסה שוב). (1)
הבקשה שנכשלה מוחזרת ל-proxy שקרא לה.
זה פותח את מפסק המעגל ומתקשר לשירות הבא עבור בקשות עוקבות. (2)

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

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

ולבסוף אתה שואל: "האם זה ניתן להתאמה אישית?"

עכשיו אתם מוכנים למסע ימי – ובואו להכיר את Control Plane.

מטוס בקרה

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

אינטראקציה של מישור בקרה עם מישור נתונים

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

קשר שירותים לאיסטיו

תיארנו את הקשר של Istio לשירותים, אבל לא להיפך: איך השירותים קשורים לאיסטיו?

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

אִיוּר ויקטוריה דימיטראקופולוס: איך אתה אוהב את המים? - מה זה בכלל מים?

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

די לתיאוריה - בואו נוציא את הידע הזה לפועל!

איסטיו בפועל

Istio דורש אשכול Kubernetes עם לפחות 4 vCPUs ו-8 GB של זיכרון RAM זמין. כדי להעלות את האשכול במהירות ולעקוב אחר ההוראות מהמאמר, אני ממליץ להשתמש ב-Google Cloud Platform, המציעה משתמשים חדשים חינם $300.

לאחר יצירת האשכול והגדרת גישה ל-Kubernetes דרך כלי השירות המסוף, תוכל להתקין את Istio דרך מנהל החבילות של Helm.

התקנת הגה

התקן את לקוח Helm במחשב שלך כמתואר ב תיעוד רשמי. נשתמש בו כדי ליצור תבניות להתקנת Istio בסעיף הבא.

התקנת Istio

הורד משאבי Istio מ המהדורה האחרונה (הקישור של המחבר המקורי לגרסה 1.0.5 שונה לגרסה הנוכחית, כלומר 1.0.6 - בערך תרגום), חלץ את התוכן לספרייה אחת, שאליה אתייחס [istio-resources].

לזיהוי קל של משאבי Istio, צור מרחב שמות באשכול K8s istio-system:

$ kubectl create namespace istio-system

השלם את ההתקנה על ידי ניווט לספרייה [istio-resources] והפעלת הפקודה:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

פקודה זו תוציא את רכיבי המפתח של Istio לקובץ istio.yaml. שינינו לעצמנו את התבנית הסטנדרטית על ידי ציון הפרמטרים הבאים:

global.mtls.enabled מותקן ב false (כלומר, אימות mTLS מושבת - בערך תרגום)כדי לפשט את תהליך ההיכרויות שלנו;
tracing.enabled מאפשר מעקב אחר בקשות עם Jaeger;
kiali.enabled מתקינה את Kiali לתוך אשכול כדי להמחיש שירותים ותעבורה;
grafana.enabled מתקין את Grafana כדי להמחיש את המדדים שנאספו.

החל את המשאבים שנוצרו עם הפקודה:

$ kubectl apply -f istio.yaml

התקנת Istio באשכול הושלמה! המתן עד שכל התרמילים במרחב השמות istio-system תוכל Running או Completedעל ידי הפעלת הפקודה למטה:

$ kubectl get pods -n istio-system

כעת אנו מוכנים להמשיך לסעיף הבא, בו נעלה ונפעיל את האפליקציה.

ארכיטקטורת יישומים של ניתוח סנטימנטים

הבה נשתמש בדוגמה של אפליקציית המיקרו-שירות של Sentiment Analysis המשמשת כבר שהוזכרה מאמר מבוא ל-Kubernetes. זה מורכב מספיק כדי להראות את האפשרויות של איסטיו בפועל.

האפליקציה מורכבת מארבעה שירותי מיקרו:

שירות SA-Frontend, המשרת את האפליקציה הקדמית ב-Reactjs;
שירות SA WebApp, המשרת שאילתות ניתוח סנטימנט;
שירות SA Logicשמבצעת את עצמה ניתוח הסנטימנט;
שירות משוב SA, המקבל משוב מהמשתמשים על דיוק הניתוח שבוצע.

בתרשים זה, בנוסף לשירותים, אנו רואים גם את Ingress Controller, אשר ב-Kubernetes מנתב בקשות נכנסות לשירותים המקבילים. Istio משתמש בקונספט דומה כחלק מ-Ingress Gateway, שפרטיו יגיעו בהמשך.

הפעלת אפליקציה עם פרוקסי מ-Istio

לפעולות נוספות המוזכרות במאמר, שכבו את המאגר שלכם istio-mastery. הוא מכיל את היישום והמניפסטים עבור Kubernetes ו-Istio.

הכנסת קרונות צד

ניתן לבצע הכנסה באופן אוטומטי או באופן ידני. כדי להכניס אוטומטית מכולות צדדיות, עליך להגדיר את התווית למרחב השמות istio-injection=enabled, שנעשה על ידי הפקודה הבאה:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

כעת כל פוד שייפרס במרחב השמות המוגדר כברירת מחדל (default) יקבל את מיכל הצד שלו. כדי לאמת זאת, בואו נפרוס יישום בדיקה על ידי מעבר לספריית הבסיס של המאגר [istio-mastery] ולהריץ את הפקודה הבאה:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

לאחר פריסת השירותים, בדוק שלפודים יש שני מיכלים כל אחד (עם השירות עצמו והצד שלו) על ידי הפעלת הפקודה kubectl get pods ולוודא כי מתחת לעמוד READY הערך שצוין 2/2, המסמל ששני המכלים פועלים:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

מבחינה ויזואלית זה נראה כך:

פרוקסי שליח באחד התרמילים

כעת כשהאפליקציה פועלת, נצטרך לאפשר לתנועה נכנסת להיכנס לאפליקציה.

Ingress Gateway

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

רכיב Ingress Gateway והשירות שמעביר אותו החוצה הותקנו על האשכול במהלך התקנת Istio. כדי לברר את כתובת ה-IP החיצונית של שירות, הפעל:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

אנו נמשיך לגשת לאפליקציה באמצעות ה-IP הזה (אני אתייחס אליו כ-EXTERNAL-IP), אז מטעמי נוחות, נכתוב את הערך למשתנה:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

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

משאב שער

Gateway הוא CRD (Custom Resource Definition) ב-Kubernetes, המוגדר לאחר התקנת Istio באשכול ומאפשר את היכולת לציין פורטים, פרוטוקול ומארחים עבורם אנו רוצים לאפשר תעבורה נכנסת.

במקרה שלנו, אנו רוצים לאפשר תעבורת HTTP ביציאה 80 עבור כל המארחים. הבעיה מתממשת על ידי ההגדרה הבאה (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

תצורה זו אינה זקוקה להסבר מלבד הבורר istio: ingressgateway. עם בורר זה, אנו יכולים לציין על איזה Ingress Gateway להחיל את התצורה. במקרה שלנו, מדובר בבקר Ingress Gateway, שהותקן כברירת מחדל ב-Istio.

התצורה מוחלת על ידי קריאה לפקודה הבאה:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

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

משאב שירות וירטואלי

ה-VirtualService אומר ל-Ingress Gateway כיצד לנתב בקשות המותרות בתוך האשכול.

בקשות לאפליקציה שלנו המגיעות דרך http-gateway חייבות להישלח לשירותי sa-frontend, sa-web-app ו-sa-feedback:

מסלולים להגדרה עם VirtualServices

שקול את הבקשות שיש לשלוח אל SA-Frontend:

התאמה מדויקת לאורך הדרך / יש לשלוח אל SA-Frontend כדי לקבל index.html;
נתיבים עם קידומת /static/* יש לשלוח אל SA-Frontend כדי להשתמש בקבצים סטטיים ב-frontend, כגון CSS ו-JavaScript;
נתיבים התואמים את הביטוי הרגולרי '^.*.(ico|png|jpg)$', יש לשלוח ל-SA-Frontend, כי אלו התמונות המוצגות בעמוד.

היישום מושג על ידי התצורה הבאה (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*.(ico|png|jpg) Важные моменты: Этот VirtualService относится к запросам, приходящим через http-gateway; В destination определяется сервис, куда отправляются запросы. Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности. Применим VirtualService вызовом: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так: Конфигурация Istio-IngressGateway для маршрутизации запросов Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились. Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.). Kiali : наблюдаемость Чтобы попасть в административный интерфейс Kiali, выполните следующую команду: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana. Grafana: визуализация метрик Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики: Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "I love yogobella"}'; sleep .8; done Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени. Наконец, посмотрим на трассировку запросов в сервисах. Jaeger : трассировка Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже: Типовой пример случайного неудачного запроса Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков… Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация: Для идентификации запроса используется TraceId В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам: Этот трейс показывает: Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app. В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.) Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде. С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app. … Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже: (A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян. Необходимо учитывать (пробрасывать) следующие заголовки: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости. Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core. Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.! Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована. P.S. от переводчика Читайте также в нашем блоге: «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация); «Conduit — легковесный service mesh для Kubernetes»; «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»; «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»; «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?». Источник: habr.com

route: - destination: host: sa-frontend # 2 port: number: 80
נקודות חשובות:

שירות וירטואלי זה מתייחס לבקשות המגיעות http-gateway;
В destination מגדיר את השירות שאליו נשלחות הבקשות.

שים לב: התצורה שלמעלה מאוחסנת בקובץ sa-virtualservice-external.yaml, שמכיל גם הגדרות לניתוב ל-SA-WebApp ו-SA-Feedback, אך קוצר כאן במאמר לקיצור.

החל VirtualService על ידי התקשרות:

שים לב: כאשר אנו צורכים משאבי Istio, שרת ה-API של Kubernetes יוצר אירוע שמתקבל במישור הבקרה של Istio, ולאחר מכן התצורה החדשה מוחלת על פרוקסי ה-Envoy של כל פוד. ונראה שהבקר של Ingress Gateway הוא שליח אחר שהוגדר במישור הבקרה. כל זה נראה כך בתרשים:

תצורת Istio-IngressGateway לניתוב בקשות

ניתוח סנטימנט זמין כעת ב- http://{EXTERNAL-IP}/. אל תדאג אם אתה מקבל סטטוס לא נמצא: לפעמים לוקח קצת יותר זמן עד שהתצורה נכנסת לתוקף ומטמונים של Envoy מתעדכנים.

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

קיאלי: צפייה

כדי להגיע לממשק הניהול של Kiali, הפעל את הפקודה הבאה:

...ולפתוח http://localhost:20001/על ידי כניסה כ-admin/admin. כאן תמצאו תכונות שימושיות רבות, למשל, לבדיקת התצורה של רכיבי Istio, להמחיש שירותים ממידע שנאסף על ידי יירוט בקשות רשת, לקבל תשובות לשאלות "מי יוצר קשר עם מי?", "איזו גרסה של השירות חווה כישלונות?" וכולי. באופן כללי, חקור את האפשרויות של Kiali לפני שתמשיך להמחיש מדדים עם Grafana.

גרפנה: הדמיה של מדדים

המדדים שנאספו ב-Istio מגיעים ל-Prometheus ומוצגים ב-Grafana. כדי להגיע לממשק הניהול של Grafana, הפעל את הפקודה למטה ואז פתח http://localhost:3000/:

על ידי לחיצה על התפריט עמוד הבית למעלה משמאל ובחר לוח המחוונים של שירות Istio בפינה השמאלית העליונה, התחל עם שירות sa-web-appכדי להציג את המדדים שנאספו:

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

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

לבסוף, בואו נסתכל על מעקב אחר בקשות בשירותים.

ייגר: איתור

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

דוגמה טיפוסית לבקשה אקראית שנכשלה

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

מדובר בבעיה נרחבת בשירותי מיקרו ונפתרת על ידי מערכות מעקב מבוזרות, שבהן השירותים מעבירים כותרת ייחודית זה לזה, ולאחר מכן המידע הזה מנותב למערכת המעקב, שם הוא מושווה לנתוני הבקשות. הנה המחשה:

TraceId משמש לזיהוי הבקשה

Istio משתמשת ב-Jaeger Tracer, המיישמת מסגרת OpenTracing API עצמאית של ספקים. אתה יכול לגשת לממשק המשתמש של Jaeger עם הפקודה הבאה:

עכשיו לך ל http://localhost:16686/ ובחר שירות sa-web-app. אם השירות אינו מוצג בתפריט הנפתח, הצג/צור פעילות בעמוד ועדכן את הממשק. לאחר מכן לחץ על הכפתור מצא עקבות, שיציג את העקבות העדכניות ביותר - בחר כל - מידע מפורט על כל העקבות יופיע:

עקבות זו מראה:

הבקשה מגיעה istio-ingressgateway (זוהי האינטראקציה הראשונה עם אחד השירותים, ונוצר Trace ID עבור הבקשה), ולאחר מכן השער שולח את הבקשה לשירות sa-web-app.
בשירות sa-web-app הבקשה נאספת על ידי ה-Envoy הצד, "ילד" נוצר בטווח (בגלל זה אנחנו רואים את זה בעקבות) ומופנה מחדש למיכל sa-web-app. (לְהַקִיף - יחידת עבודה הגיונית ביגר, בעלת שם, שעת תחילת הפעולה ומשך הזמן שלה. ניתן לקנן ולהזמין טווחים. גרף אציקלי מכוון של טווחים יוצר עקבות. - משוער. תרגום)
כאן הבקשה מעובדת בשיטה ניתוח הסנטימנט. עקבות אלו כבר נוצרו על ידי האפליקציה, כלומר. הם דרשו שינויים בקוד.
מרגע זה מופעלת בקשת POST ב סא-לוגיקה. יש להעביר מזהה מעקב מ sa-web-app.
...

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

(א) העברת כותרות היא באחריות Istio; (ב) השירותים אחראים לכותרות

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

יש לקחת בחשבון את הכותרות הבאות (להעביר):

זו משימה פשוטה, אבל כדי לפשט את היישום שלה, יש כבר ספריות רבות - לדוגמה, בשירות sa-web-app, לקוח RestTemplate מעביר את הכותרות האלה אם אתה פשוט מוסיף את הספריות Jaeger ו-OpenTracing ל התלות שלה.

שים לב שהיישום Sentiment Analysis מדגים יישומים ב-Flask, Spring ו-ASP.NET Core.

עכשיו, כשברור מה אנחנו מקבלים מהקופסה (או כמעט מחוץ לקופסה), בואו נסתכל על כוונון ניתוב, ניהול תעבורת רשת, אבטחה ועוד!

הערה. תרגום: קראו על זה בחלק הבא של חומרים ב-Istio מאת Rinor Maloku, שתרגומם יגיע בבלוג שלנו בעתיד הקרוב. עדכון (14 במרץ): החלק השני כבר פורסם.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

"חזרה לשירותי מיקרו עם Istio": חלק 2 (ניתוב, בקרת תנועה), חלק 3 (אימות והרשאה);
«Conduit - רשת שירות קלת משקל עבור Kubernetes";
«מהי רשת שירות ולמה אני צריך אותה [עבור אפליקציית ענן עם מיקרו-שירותים]?";
«מדריך מאויר לרשת ב-Kubernetes. חלקים 1 ו-2";
«כיצד הגיעה מכולה צדדית זו לכאן [ב-Kubernetes]?".

מקור: www.habr.com