Istio bilan mikroservislarga qaytish. 1-qism

Eslatma. tarjima.: Xizmat tarmoqlari, albatta, mikroservis arxitekturasidan keyingi ilovalar uchun zamonaviy infratuzilmada tegishli yechimga aylandi. Istio ko'plab DevOps muhandislarining og'zida bo'lishi mumkin bo'lsa-da, bu juda yangi mahsulot bo'lib, u taqdim etayotgan imkoniyatlar jihatidan har tomonlama bo'lsa-da, tanishish uchun ko'p vaqt talab qilishi mumkin. Orange Networks telekommunikatsiya kompaniyasida yirik mijozlar uchun bulutli hisoblash uchun mas'ul bo'lgan nemis muhandisi Rinor Maloku Istio-ga tez va chuqur sho'ng'ish imkonini beruvchi ajoyib materiallar seriyasini yozdi. U o'z hikoyasini Istio umuman nima qila olishi va qanday qilib tezda o'z ko'zingiz bilan ko'rishingiz mumkinligi bilan boshlaydi.

Istio — Google, IBM va Lyft jamoalari bilan hamkorlikda ishlab chiqilgan Ochiq manba loyihasi. U mikroservislarga asoslangan ilovalarda yuzaga keladigan murakkabliklarni hal qiladi, masalan:

• transport boshqaruvi: vaqt tugashi, qayta urinishlar, yuklarni muvozanatlash;
• Xavfsizlik: oxirgi foydalanuvchi autentifikatsiyasi va avtorizatsiyasi;
• Kuzatish qobiliyati: kuzatish, kuzatish, jurnalga yozish.

Bularning barchasi dastur darajasida hal qilinishi mumkin, ammo bundan keyin sizning xizmatlaringiz endi "mikro" bo'lmaydi. Ushbu muammolarni hal qilish uchun barcha qo'shimcha harakatlar to'g'ridan-to'g'ri biznes qiymati uchun ishlatilishi mumkin bo'lgan kompaniya resurslarini behuda sarflashdir. Keling, bir misolni ko'rib chiqaylik:

Loyiha menejeri: Fikr-mulohaza funksiyasini kiritish qancha vaqt oladi?
Tuzuvchi: Ikkita sprint.

Deputat: Nima?.. Bu shunchaki CRUD!
Javob: CRUDni amalga oshirish oson qism, lekin biz hali ham foydalanuvchilar va xizmatlarni autentifikatsiya qilishimiz va avtorizatsiya qilishimiz kerak. Tarmoq ishonchsiz bo'lgani uchun siz takroriy so'rovlarni amalga oshirishingiz kerak bo'ladi, shuningdek elektron to'xtatuvchining namunasi mijozlarda. Bundan tashqari, butun tizim ishdan chiqmasligiga ishonch hosil qilish uchun sizga vaqt autlari kerak bo'ladi va bulkheadlar (ikkalasi eslatib o'tilgan naqshlar haqida batafsil ma'lumot olish uchun maqolaning keyingi qismiga qarang - taxminan tarjimasi.), va muammolarni aniqlash, monitoring qilish, kuzatish, […]

MP: Oh, keling, ushbu xususiyatni Mahsulot xizmatiga kiritaylik.

Menimcha, fikr aniq: bitta xizmatni qo'shish uchun zarur bo'lgan qadamlar va harakatlar juda katta. Ushbu maqolada biz Istio yuqorida aytib o'tilgan barcha murakkabliklarni (bu biznes mantig'i uchun mo'ljallanmagan) xizmatlardan qanday olib tashlashini ko'rib chiqamiz.

nota: Ushbu maqolada siz Kubernetes bo'yicha amaliy ma'lumotlarga ega ekanligingizni taxmin qiladi. Aks holda, men o'qishni tavsiya qilaman mening Kubernetesga kirishim va shundan keyingina ushbu materialni o'qishni davom eting.

Istio g'oya

Istio bo'lmagan dunyoda bir xizmat boshqasiga to'g'ridan-to'g'ri so'rovlar yuboradi va ishlamay qolganda, xizmat uni o'zi hal qilishi kerak: yangi urinishni amalga oshirish, kutish vaqtini ta'minlash, o'chirgichni ochish va hokazo.

Kubernetesdagi tarmoq trafigi

Istio xizmatlardan butunlay ajratilgan va tarmoq aloqasiga xalaqit beradigan ixtisoslashtirilgan yechimni taklif etadi. Va shunday qilib, u amalga oshiradi:

• xatolarga chidamlilik: Javobdagi holat kodiga asoslanib, so'rov bajarilmaganligini tushunadi va uni qayta bajaradi.
• Kanareykalarni tarqatish: so'rovlarning faqat belgilangan foizini xizmatning yangi versiyasiga yo'naltiradi.
• Monitoring va ko'rsatkichlar: Xizmat javob berish uchun qancha vaqt kerak bo'ldi?
• Kuzatish va kuzatish: Har bir so'rovga maxsus sarlavhalar qo'shadi va ularni klaster bo'ylab kuzatib boradi.
• Xavfsizlik: JWT tokenini oladi, foydalanuvchilarni autentifikatsiya qiladi va avtorizatsiya qiladi.

Bular sizni qiziqtiradigan imkoniyatlarning bir nechtasi (haqiqatdan ham bir nechtasi!). Endi texnik tafsilotlarga o'taylik!

Istio arxitekturasi

Istio barcha tarmoq trafigini to'xtatadi va unga bir qator qoidalarni qo'llaydi, har bir podkaga yonbosh konteyner ko'rinishidagi aqlli proksi-serverni kiritadi. Barcha imkoniyatlarni faollashtiradigan proksi-serverlar a hosil qiladi Ma'lumotlar tekisligi, va ular yordamida dinamik ravishda sozlanishi mumkin Boshqaruv tekisligi.

Ma'lumotlar tekisligi

Podkalarga kiritilgan proksi-serverlar Istio-ga bizga kerakli talablarni osongina qondirish imkonini beradi. Misol uchun, qayta urinish va o'chirgich funktsiyalarini tekshiramiz.

Qayta urinishlar va elektron uzilishlar Envoyda qanday amalga oshiriladi

Xulosa:

1. elchisi (biz tarqatiladigan yonbosh konteynerida joylashgan proksi-server haqida gapiramiz alohida mahsulot - taxminan. tarjima.) B xizmatining birinchi instantsiyasiga so'rov yuboradi va bajarilmaydi.
2. Elchi Sidecar yana urinib ko'radi (qayta urinish). (1)
3. So'rov bajarilmadi va uni chaqirgan proksi-serverga qaytariladi.
4. Bu Circuit Breakerni ochadi va keyingi so'rovlar uchun keyingi xizmatni chaqiradi. (2)

Bu shuni anglatadiki, siz boshqa Qayta urinish kutubxonasidan foydalanishingiz shart emas, X, Y yoki Z dasturlash tillarida o'chirish va xizmat ko'rsatishni ochishni o'zingiz amalga oshirishingiz shart emas. Bularning barchasi va yana ko'p narsalarni qutidan tashqarida topish mumkin. Istio-da va talab qilmaydi Yo'q koddagi o'zgarishlar.

Ajoyib! Endi siz Istio bilan sayohatga chiqmoqchi bo'lishingiz mumkin, ammo sizda hali ham shubhalar, ochiq savollar bor. Agar bu hayotdagi barcha holatlar uchun universal echim bo'lsa, unda sizda tabiiy shubha bor: aslida bunday echimlarning barchasi har qanday vaziyat uchun yaroqsiz bo'lib chiqadi.

Va nihoyat siz so'raysiz: "Uni sozlash mumkinmi?"

Endi siz dengiz sayohatiga tayyorsiz, keling, boshqaruv samolyoti bilan tanishamiz.

Boshqaruv tekisligi

U uchta komponentdan iborat: Uchuvchi, Mikser и Citadel, ular Envoyslarni trafikni yo'naltirish, siyosatlarni amalga oshirish va telemetriya ma'lumotlarini yig'ish uchun sozlash uchun birgalikda ishlaydi. Sxematik ravishda hammasi quyidagicha ko'rinadi:

Boshqaruv tekisligining ma'lumotlar tekisligi bilan o'zaro ta'siri

Elchilar (ya'ni ma'lumotlar tekisligi) yordamida tuzilgan Kubernetes CRD (Maxsus Resurs Ta'riflari) Istio tomonidan belgilangan va shu maqsadda maxsus mo'ljallangan. Bu siz uchun nimani anglatadi, ular Kubernetesdagi tanish sintaksisga ega bo'lgan boshqa manba bo'lib ko'rinadi. Yaratilgandan so'ng, ushbu resurs boshqaruv samolyoti tomonidan olinadi va Elchilarga qo'llaniladi.

Xizmatlarning Istio bilan aloqasi

Biz Istio-ning xizmatlarga bo'lgan munosabatini tasvirlab berdik, lekin aksincha emas: xizmatlar Istio bilan qanday bog'liq?

To‘g‘risini aytsam, xizmatlar o‘zlariga “Suv nima?” deb so‘rashganda, Istio borligini baliq suvdagidek bilishadi.

Illustration Viktoriya Dimitrakopulos: - Suvni qanday yoqtirasiz? - Suv nima?

Shunday qilib, siz ishlaydigan klasterni olishingiz mumkin va Istio komponentlarini joylashtirgandan so'ng, unda joylashgan xizmatlar ishlashni davom ettiradi va ushbu komponentlarni olib tashlaganingizdan so'ng, hamma narsa yana yaxshi bo'ladi. Bu holda siz Istio tomonidan taqdim etilgan imkoniyatlardan mahrum bo'lishingiz aniq.

Yetarlicha nazariya - keling, bu bilimlarni amalda qo'llaylik!

Istio amalda

Istio kamida 4 vCPU va 8 GB operativ xotiraga ega Kubernetes klasterini talab qiladi. Klasterni tezda o'rnatish va maqoladagi ko'rsatmalarga amal qilish uchun men yangi foydalanuvchilarni taklif qiladigan Google Cloud Platform-dan foydalanishni tavsiya qilaman. bepul $ 300.

Klaster yaratgandan va konsol yordam dasturi orqali Kubernetes-ga kirishni sozlaganingizdan so'ng, Istio-ni Helm paket menejeri orqali o'rnatishingiz mumkin.

Rulda o'rnatish

Helm mijozini bo'limda tavsiflanganidek kompyuteringizga o'rnating rasmiy hujjatlar. Biz bundan keyingi bo'limda Istio-ni o'rnatish uchun shablonlarni yaratish uchun foydalanamiz.

Istio o'rnatilmoqda

Istio resurslarini yuklab oling oxirgi reliz (asl muallifning 1.0.5 versiyasiga havolasi hozirgisiga o'zgartirildi, ya'ni 1.0.6 - taxminan tarjimasi), tarkibni bitta katalogga chiqarib oling, men bundan buyon chaqiraman [istio-resources].

Istio resurslarini osongina aniqlash uchun K8s klasterida nom maydoni yarating istio-system:

$ kubectl create namespace istio-system

Katalogga o'tish orqali o'rnatishni yakunlang [istio-resources] va buyruqni ishga tushirish:

$ 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

Bu buyruq Istio ning asosiy komponentlarini faylga chiqaradi istio.yaml. Biz quyidagi parametrlarni belgilab, standart shablonni o'zimizga mos ravishda o'zgartirdik:

• global.mtls.enabled ichida o'rnatilgan false (ya'ni, mTLS autentifikatsiyasi o'chirilgan - taxminan)tanishish jarayonini soddalashtirish;
• tracing.enabled Jaeger yordamida so'rovlarni kuzatishni o'z ichiga oladi;
• kiali.enabled xizmatlar va trafikni ko'rish uchun Kiali'ni klasterga o'rnatadi;
• grafana.enabled yig'ilgan ko'rsatkichlarni ko'rish uchun Grafana-ni o'rnatadi.

Yaratilgan resurslardan buyruq bilan foydalanamiz:

$ kubectl apply -f istio.yaml

Istio-ni klasterga o'rnatish tugallandi! Barcha podlar nomlar maydonida bo'lguncha kuting istio-system qila oladi Running yoki Completedquyidagi buyruqni ishga tushirish orqali:

$ kubectl get pods -n istio-system

Endi biz dasturni ishga tushiradigan keyingi bo'limda davom etishga tayyormiz.

Sentiment Analysis ilovasining arxitekturasi

Keling, yuqorida aytib o'tilganda ishlatiladigan Sentiment Analysis mikroservis ilovasi misolidan foydalanaylik Kubernetesga kirish maqolasi. Bu Istioning imkoniyatlarini amalda ko'rsatish uchun etarlicha murakkab.

Ilova to'rtta mikroservisdan iborat:

1. xizmat SA-Frontend, bu Reactjs ilovasining old qismiga xizmat qiladi;
2. xizmat SA-WebApp, bu his-tuyg'ularni tahlil qilish so'rovlariga xizmat qiladi;
3. xizmat SA-Mantiq, bu o'zini o'zi bajaradi hissiyotlarni tahlil qilish;
4. xizmat SA - fikr-mulohaza, bu foydalanuvchilarning tahlilning to'g'riligi haqida fikr-mulohazalarini oladi.

Ushbu diagrammada xizmatlarga qo'shimcha ravishda biz Kubernetes-da kiruvchi so'rovlarni tegishli xizmatlarga yo'naltiradigan Ingress Controller-ni ham ko'ramiz. Istio o'zining kirish shlyuzida shunga o'xshash kontseptsiyadan foydalanadi, bu haqda batafsilroq ma'lumot beriladi.

Ilovani Istio proksi-server bilan ishga tushirish

Maqolada aytib o'tilgan boshqa operatsiyalar uchun omboringizni klonlang ustalik. Unda Kubernetes va Istio uchun dastur va manifatlar mavjud.

Yon vagonlarni o'rnatish

Kiritish amalga oshirilishi mumkin avtomatik ravishda yoki qo'lda. Avtomatik ravishda yonbosh konteynerlarini kiritish uchun siz nomlar maydoniga yorliq o'rnatishingiz kerak bo'ladi istio-injection=enabled, bu quyidagi buyruq bilan amalga oshiriladi:

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

Endi standart nom maydonida joylashtiriladigan har bir pod (default) o'zining yonbosh konteynerini oladi. Buni tekshirish uchun, keling, omborning ildiz katalogiga o'tish orqali test dasturini joylashtiramiz [istio-mastery] va quyidagi buyruqni ishga tushiring:

$ 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

Xizmatlarni ishga tushirgandan so'ng, keling, buyruqni ishga tushirish orqali podkalarda ikkita konteyner (xizmatning o'zi va uning yonboshi bilan) mavjudligini tekshiramiz. kubectl get pods va ustun ostida ekanligiga ishonch hosil qiling READY belgilangan qiymat 2/2, ikkala konteyner ishlayotganini bildiradi:

$ 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

Vizual ravishda u quyidagicha ko'rinadi:

Podkalardan birida elchi proksi-server

Endi ilova ishga tushdi va biz kiruvchi trafikni ilovaga kirishiga ruxsat berishimiz kerak.

Kirish shlyuzi

Bunga erishish uchun eng yaxshi amaliyot (klasterdagi trafikka ruxsat berish) orqali Kirish shlyuzi Istio-da, bu klasterning "chekkasida" joylashgan va Istio-ning marshrutlash, yukni muvozanatlash, xavfsizlik va kiruvchi trafikni kuzatish kabi xususiyatlarini yoqish imkonini beradi.

Ingress Gateway komponenti va uni tashqariga yo'naltiruvchi xizmat Istio o'rnatilishi vaqtida klasterga o'rnatilgan. Xizmatning tashqi IP manzilini bilish uchun quyidagilarni bajaring:

$ 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

Biz ushbu IP-dan foydalanib dasturga kirishni davom ettiramiz (men uni EXTERNAL-IP deb nomlayman), shuning uchun qulaylik uchun qiymatni o'zgaruvchiga yozamiz:

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

Agar siz hozirda ushbu IP-ga brauzer orqali kirishga harakat qilsangiz, siz "Xizmat mavjud emas" xatosini olasiz, chunki sukut bo'yicha Istio barcha kiruvchi trafikni bloklaydi, Gateway hali aniqlanmagan.

Gateway resursi

Gateway Kubernetesdagi CRD (Maxsus Resurs Ta'rifi) bo'lib, Istio-ni klasterga o'rnatgandan so'ng aniqlanadi va biz kiruvchi trafikka ruxsat bermoqchi bo'lgan portlar, protokollar va xostlarni belgilash imkoniyatini beradi.

Bizning holatda, biz barcha xostlar uchun 80-portda HTTP trafigiga ruxsat berishni xohlaymiz. Vazifa quyidagi ta'rif bilan amalga oshiriladi (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:
- "*"

Ushbu konfiguratsiya selektordan tashqari hech qanday tushuntirishga muhtoj emas istio: ingressgateway. Ushbu selektor yordamida biz konfiguratsiyani qaysi Ingress Gatewayga qo'llashni belgilashimiz mumkin. Bizning holatda, bu Istio-da sukut bo'yicha o'rnatilgan Ingress Gateway kontrolleri.

Konfiguratsiya quyidagi buyruqni chaqirish orqali qo'llaniladi:

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

Shlyuz endi 80-portga kirish imkonini beradi, lekin so‘rovlarni qayerga yo‘naltirishni bilmaydi. Buning uchun sizga kerak bo'ladi Virtual xizmatlar.

VirtualService resursi

VirtualService kirish shlyuziga klaster ichida ruxsat etilgan so'rovlarni qanday yo'naltirish kerakligini aytadi.

Ilovaga http-shlyuz orqali keladigan so'rovlar sa-frontend, sa-web-app va sa-feedback xizmatlariga yuborilishi kerak:

VirtualServices bilan sozlanishi kerak bo'lgan marshrutlar

Keling, SA-Frontendga yuborilishi kerak bo'lgan so'rovlarni ko'rib chiqaylik:

• Yo'lda aniq moslik / index.html olish uchun SA-Frontendga yuborilishi kerak;
• Prefiksli yo'llar /static/* CSS va JavaScript kabi frontendda ishlatiladigan statik fayllarni olish uchun SA-Frontendga yuborilishi kerak;
• Muntazam ifoda bilan mos keladigan yo'llar '^.*.(ico|png|jpg)$', SA-Frontendga yuborilishi kerak, chunki Bu sahifada ko'rsatilgan rasmlar.

Amalga oshirish quyidagi konfiguratsiya orqali amalga oshiriladi (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

Muhim fikrlar:

 Ushbu VirtualXizmat orqali kelgan so'rovlarga ishora qiladi http-shlyuz;
 В destination So'rovlar yuboriladigan xizmat aniqlanadi.

nota: Yuqoridagi konfiguratsiya faylda saqlanadi sa-virtualservice-external.yaml, unda SA-WebApp va SA-Feedback-da marshrutlash sozlamalari ham mavjud, ammo bu yerda qisqachalik uchun maqolada qisqartirilgan.
Keling, qo'ng'iroq qilish orqali VirtualService-dan foydalanamiz:

nota: Istio resurslarini iste'mol qilganimizda, Kubernetes API Server Istio Control Plane tomonidan qabul qilinadigan voqea yaratadi va shundan so'ng yangi konfiguratsiya har bir pod's Envoy proksi-serverlariga qo'llaniladi. Va Ingress Gateway kontrolleri Boshqaruv tekisligida sozlangan boshqa elchi bo'lib ko'rinadi. Bularning barchasi diagrammada shunday ko'rinadi:


So'rovni yo'naltirish uchun Istio-IngressGateway konfiguratsiyasi
Sentiment Analysis ilovasi endi mavjud http://{EXTERNAL-IP}/. Agar topilmadi maqomini olsangiz, tashvishlanmang: Ba'zan konfiguratsiya kuchga kirishi va Envoy keshlarini yangilash uchun biroz ko'proq vaqt ketadi.
Davom etishdan oldin, trafik yaratish uchun ilova bilan biroz o'ynang. (uning mavjudligi keyingi harakatlarda aniqlik uchun zarur - taxminan. Tarjima.).
Kiali: kuzatuvchanlik
Kiali ma'muriy interfeysiga kirish uchun quyidagi buyruqni bajaring:

... va oching http://localhost:20001/, admin/admin sifatida tizimga kiring. Bu erda siz ko'plab foydali funktsiyalarni topasiz, masalan, Istio komponentlari konfiguratsiyasini tekshirish, tarmoq so'rovlarini ushlab qolish natijasida to'plangan ma'lumotlardan foydalangan holda xizmatlarni vizualizatsiya qilish, "Kim kim bilan bog'lanmoqda?", "Xizmatning qaysi versiyasini boshdan kechirmoqda?" Degan savollarga javob olasiz. muvaffaqiyatsizliklar?" va h.k. Umuman olganda, Grafana yordamida ko'rsatkichlarni vizualizatsiya qilishga o'tishdan oldin Kiali imkoniyatlarini o'rganing.

Grafana: o'lchovlarni vizualizatsiya qilish
Istio-da to'plangan ko'rsatkichlar Prometeyga kiradi va Grafana yordamida ingl. Grafana ma'muriy interfeysiga kirish uchun quyidagi buyruqni ishga tushiring va keyin oching http://localhost:3000/:

Menyuni bosish Bosh sahifa yuqori chap va tanlash Istio xizmati asboblar paneli yuqori chap burchakda, xizmat bilan boshlang sa-veb-ilovato'plangan ko'rsatkichlarni ko'rish uchun:

Bu erda bizni bo'sh va mutlaqo zerikarli ishlash kutmoqda - rahbariyat buni hech qachon ma'qullamaydi. Quyidagi buyruq bilan kichik yuk yaratamiz:

Endi bizda ancha yaxshi grafikalar mavjud va ularga qo'shimcha ravishda monitoring uchun ajoyib Prometey vositalari va ko'rsatkichlarni vizualizatsiya qilish uchun Grafana mavjud bo'lib, ular vaqt o'tishi bilan xizmatlarning ishlashi, sog'lig'i, yaxshilanishlari / degradatsiyasi haqida bilib olishimizga imkon beradi.
Va nihoyat, xizmatlardagi so'rovlarni kuzatishni ko'rib chiqaylik.
Jaeger: kuzatish
Bizga kuzatuv kerak bo'ladi, chunki bizda qancha ko'p xizmatlar mavjud bo'lsa, muvaffaqiyatsizlik sababini aniqlash shunchalik qiyin bo'ladi. Keling, quyidagi rasmdagi oddiy holatni ko'rib chiqaylik:


Tasodifiy bajarilmagan so'rovning odatiy misoli
So'rov keladi, tushadi - sababi nima? Birinchi xizmat? Yoki ikkinchisimi? Ikkalasida ham istisnolar mavjud - keling, har birining jurnalini ko'rib chiqaylik. Qanchalik tez-tez o'zingizni shunday qilyapsiz? Bizning ishimiz ishlab chiquvchilardan ko'ra ko'proq dasturiy ta'minot detektivlariga o'xshaydi...
Bu mikroservislarda keng tarqalgan muammo bo'lib, taqsimlangan kuzatuv tizimlari tomonidan hal qilinadi, bunda xizmatlar bir-biriga noyob sarlavhani uzatadi, shundan so'ng bu ma'lumot kuzatuv tizimiga uzatiladi va u erda so'rov ma'lumotlari bilan taqqoslanadi. Mana bir misol:


TraceId so'rovni aniqlash uchun ishlatiladi
Istio sotuvchidan mustaqil OpenTracing API asosini amalga oshiradigan Jaeger Tracerdan foydalanadi. Jaeger foydalanuvchi interfeysiga quyidagi buyruq bilan kirishingiz mumkin:

Endi o'ting http://localhost:16686/ va xizmatni tanlang sa-veb-ilova. Agar xizmat ochiladigan menyuda ko'rsatilmasa, sahifada faoliyatni ko'rsating/yarating va interfeysni yangilang. Shundan so'ng, tugmani bosing Izlarni toping, bu eng so'nggi izlarni ko'rsatadi - istalganini tanlang - barcha izlar haqida batafsil ma'lumot paydo bo'ladi:

Bu iz ko'rsatadi:

 So'rov keladi istio-ingressgateway (bu xizmatlardan biri bilan birinchi o'zaro aloqadir va so'rov uchun Trace ID yaratiladi), shundan so'ng shlyuz so'rovni xizmatga yuboradi. sa-veb-ilova.
 Xizmatda sa-veb-ilova so'rov Elchining yon mashinasi tomonidan qabul qilinadi, oraliqda "bola" yaratiladi (shuning uchun biz uni izlarda ko'ramiz) va konteynerga yo'naltiriladi sa-veb-ilova. (span - Jaegerdagi mantiqiy ish birligi, uning nomi, operatsiyaning boshlanish vaqti va uning davomiyligi. Oraliqlarni joylashtirish va buyurtma qilish mumkin. oraliqlarning yo'naltirilgan asiklik grafigi iz hosil qiladi. - taxminan. tarjima.)
 Bu erda so'rov usul bilan qayta ishlanadi hissiyotlarni tahlil qilish. Ushbu izlar allaqachon dastur tomonidan yaratilgan, ya'ni. ular kodni o'zgartirishni talab qildilar.
 Shu paytdan boshlab POST so'rovi boshlanadi sa-mantiq. Trace ID dan yuborilishi kerak sa-veb-ilova.
 ...

nota: 4-bosqichda dastur Istio tomonidan yaratilgan sarlavhalarni ko'rishi va ularni quyidagi rasmda ko'rsatilganidek, keyingi so'rovlarga o'tkazishi kerak:


(A) Istio sarlavhalarni yuborish uchun javobgardir; (B) Xizmatlar sarlavhalar uchun javobgardir
Istio ishning ko'p qismini bajaradi, chunki ... kiruvchi so'rovlar uchun sarlavhalarni yaratadi, har bir yonboshda yangi oraliqlarni yaratadi va ularni yo'naltiradi. Biroq, xizmatlar ichidagi sarlavhalar bilan ishlamasdan, to'liq so'rovni kuzatish yo'li yo'qoladi.
Quyidagi sarlavhalarni hisobga olish kerak:

Bu qiyin ish emas, lekin uni amalga oshirishni soddalashtirish allaqachon mavjud ko'plab kutubxonalar - masalan, sa-web-app xizmatida, agar siz shunchaki Jaeger va OpenTracing kutubxonalarini qo'shsangiz, RestTemplate mijozi ushbu sarlavhalarni yo'naltiradi. uning qaramliklari.
E'tibor bering, Sentiment Analysis ilovasi Flask, Spring va ASP.NET Core-da ilovalarni namoyish etadi.
Endi biz qutidan (yoki deyarli qutidan) nima olishimiz aniq bo'lsa, keling, nozik sozlangan marshrutlash, tarmoq trafigini boshqarish, xavfsizlik va hokazolarni ko'rib chiqaylik!
Eslatma. tarjima.: Bu haqda Rinor Malokudan olingan Istio materiallarining keyingi qismida o'qing, tarjimalari yaqin kelajakda bizning blogimizda bo'ladi. UPDATE (14 mart): Ikkinchi qism allaqachon nashr etilgan.
Tarjimondan PS
Shuningdek, bizning blogimizda o'qing:

• "Istio bilan mikroservislarga qaytish": 2-qism (marshrutlash, harakatni boshqarish), 3-qism (autentifikatsiya va avtorizatsiya);
• «Conduit - Kubernetes uchun engil xizmat ko'rsatish tarmog'i";
• «Xizmat tarmog'i nima va u menga nima uchun kerak [mikroservislar bilan bulutli ilova uchun]?";
• «Kubernetesda tarmoqqa ulanish bo'yicha tasvirlangan qo'llanma. 1 va 2-qismlar";
• «Qanday qilib bu yonbosh konteyner bu erga [Kubernetesga] tushdi?".

Manba: www.habr.com