🥇Atpakaļ uz mikropakalpojumiem ar Istio. 1. daļa

Piezīme. tulk.: Pakalpojumu tīkli noteikti ir kļuvuši par atbilstošu risinājumu mūsdienu infrastruktūrā lietojumprogrammām, kas seko mikropakalpojumu arhitektūrai. Lai gan Istio var runāt par daudziem DevOps inženieriem, tas ir diezgan jauns produkts, kas, lai gan tas ir visaptverošs tā sniegto iespēju ziņā, var prasīt ievērojamu laiku, lai iepazītos ar to. Vācu inženieris Rinors Maloku, kurš telekomunikāciju uzņēmumā Orange Networks ir atbildīgs par mākoņdatošanu lielajiem klientiem, ir uzrakstījis brīnišķīgu materiālu sēriju, kas ļauj ātri un dziļi ienirt Istio. Viņš sāk savu stāstu ar to, ko Istio vispār spēj un kā to var ātri redzēt savām acīm.

Istio — Atvērtā pirmkoda projekts, kas izstrādāts sadarbībā ar Google, IBM un Lyft komandām. Tas atrisina sarežģījumus, kas rodas uz mikropakalpojumiem balstītās lietojumprogrammās, piemēram:

Satiksmes vadība: taimauts, atkārtojumi, slodzes līdzsvarošana;
Drošība: galalietotāja autentifikācija un autorizācija;
Novērojamība: izsekošana, uzraudzība, mežizstrāde.

To visu var atrisināt lietojumprogrammas līmenī, bet pēc tam jūsu pakalpojumi vairs nebūs "mikro". Visas papildu pūles, lai atrisinātu šīs problēmas, ir uzņēmuma resursu izšķērdēšana, ko varētu tieši izmantot biznesa vērtībai. Apskatīsim piemēru:

Projekta vadītājs: Cik ilgs laiks nepieciešams, lai pievienotu atsauksmju funkciju?
Izstrādātājs: divi sprinti.

MP: Ko?.. Tas ir vienkārši CRUD!
R: CRUD veikšana ir vienkāršāka daļa, taču mums joprojām ir jāautentificē un jāautorizē lietotāji un pakalpojumi. Tā kā tīkls ir neuzticams, jums būs jāievieš atkārtoti pieprasījumi, kā arī ķēdes pārtraucēja modelis klientos. Tāpat, lai pārliecinātos, ka visa sistēma neavārē, jums būs nepieciešami noildzes un starpsienas (sīkāku informāciju par abiem minētajiem modeļiem skatīt vēlāk rakstā - apm. tulk.)un, lai atklātu problēmas, uzraudzību, izsekošanu, […]
MP: Ak, tad vienkārši ievietosim šo funkciju produkta pakalpojumā.

Domāju, ka ideja ir skaidra: viena pakalpojuma pievienošanai nepieciešamais soļu un pūļu apjoms ir milzīgs. Šajā rakstā mēs apskatīsim, kā Istio no pakalpojumiem novērš visu iepriekš minēto sarežģītību (kas nav paredzēta kā biznesa loģika).

Piezīme: Šajā rakstā tiek pieņemts, ka jums ir darba zināšanas par Kubernetes. Citādi iesaku lasīt mans ievads Kubernetes un tikai pēc tam turpiniet lasīt šo materiālu.

Istio ideja

Pasaulē, kurā nav Istio, viens pakalpojums veic tiešus pieprasījumus citam, un kļūmes gadījumā pakalpojumam tas ir jārisina pašam: jāveic jauns mēģinājums, jānodrošina taimauts, jāatver ķēdes pārtraucējs utt.

Tīkla trafika Kubernetes

Istio piedāvā specializētu risinājumu, kas ir pilnībā atdalīts no pakalpojumiem un darbojas, traucējot tīkla saziņu. Un tādējādi tas īsteno:

kļūdu tolerance: pamatojoties uz statusa kodu atbildē, tas saprot, vai pieprasījums neizdevās, un izpilda to atkārtoti.
Kanārijputniņi: novirza tikai noteiktu procentuālo daļu pieprasījumu uz jauno pakalpojuma versiju.
Uzraudzība un metrika: Cik ilgs laiks pagāja, līdz pakalpojums atbildēja?
Izsekošana un novērojamība: katram pieprasījumam pievieno īpašas galvenes un izseko tām visā klasterī.
Drošība: izgūst JWT marķieri, autentificē un autorizē lietotājus.

Šīs ir tikai dažas no iespējām (tiešām tikai dažas!), lai jūs ieintriģētu. Tagad iedziļināsimies tehniskajās detaļās!

Istio arhitektūra

Istio pārtver visu tīkla trafiku un piemēro tam noteikumu kopumu, ievietojot viedo starpniekserveri blakusvāģa konteinera formā katrā podā. Starpniekserveri, kas aktivizē visas iespējas, veido a Datu plakne, un tos var dinamiski konfigurēt, izmantojot Vadības plakne.

Datu plakne

Pākstīm ievietotie starpniekserveri ļauj Istio viegli izpildīt mums nepieciešamās prasības. Piemēram, pārbaudīsim atkārtotā mēģinājuma un ķēdes pārtraucēja funkcijas.

Kā programmā Envoy tiek īstenoti atkārtojumi un ķēdes pārtraukumi

Rezumējot:

sūtnis (mēs runājam par starpniekserveri, kas atrodas blakusvāģa konteinerā, kas tiek izplatīts kā atsevišķs produkts — apm. tulk.) nosūta pieprasījumu pakalpojuma B pirmajai instancei un neizdodas.
Sūtnis blakusvāģis mēģina vēlreiz (mēģināt vēlreiz). (1)
Pieprasījums neizdodas un tiek atgriezts starpniekserverim, kas to izsauca.
Tas atver Circuit Breaker un izsauc nākamo pakalpojumu, lai saņemtu turpmākus pieprasījumus. (2)

Tas nozīmē, ka jums nav jāizmanto cita Retry bibliotēka, jums nav pašam jāīsteno Circuit Breaking un Service Discovery programmēšanas valodā X, Y vai Z. Tas viss un daudz kas cits ir pieejams jau no iepakojuma. Istio un neprasa nē izmaiņas kodā.

Lieliski! Tagad jūs varētu vēlēties doties ceļojumā ar Istio, bet jums joprojām ir dažas šaubas, atklāti jautājumi. Ja tas ir universāls risinājums visiem dzīves gadījumiem, tad jums ir dabiskas aizdomas: galu galā visi šādi risinājumi patiesībā izrādās nepiemēroti jebkuram gadījumam.

Un visbeidzot jūs jautājat: "Vai tas ir pielāgojams?"

Tagad esi gatavs jūras braucienam, iepazīsimies ar Vadības lidmašīnu.

Vadības plakne

Tas sastāv no trim sastāvdaļām: pilots, Mikseris и Citadele, kas strādā kopā, lai konfigurētu sūtņus, lai maršrutētu satiksmi, ieviestu politikas un apkopotu telemetrijas datus. Shematiski tas viss izskatās šādi:

Vadības plaknes mijiedarbība ar datu plakni

Sūtņi (t.i., datu plakne) tiek konfigurēti, izmantojot Kubernetes CRD (Pielāgotas resursu definīcijas), ko definējis Istio un kas īpaši paredzēts šim nolūkam. Tas jums nozīmē to, ka tie šķiet tikai vēl viens Kubernetes resurss ar pazīstamu sintaksi. Kad resurss ir izveidots, to paņems vadības plakne un izmantos sūtņiem.

Pakalpojumu saistība ar Istio

Mēs esam aprakstījuši Istio attiecības ar pakalpojumiem, bet ne otrādi: kā pakalpojumi ir saistīti ar Istio?

Godīgi sakot, dienesti apzinās Istio klātbūtni tikpat labi kā zivis, kad viņi sev jautā: "Kas vispār ir ūdens?"

Ilustrācija Viktorija Dimitrakopulosa: - Kā tev patīk ūdens? - Kas vispār ir ūdens?

Tādējādi jūs varat paņemt strādājošu klasteru un pēc Istio komponentu izvietošanas tajā esošie servisi turpinās strādāt, un pēc šo komponentu noņemšanas viss atkal būs kārtībā. Ir skaidrs, ka šajā gadījumā jūs zaudēsiet Istio sniegtās iespējas.

Pietiek teorijas – pielietosim šīs zināšanas praksē!

Istio praksē

Istio ir nepieciešams Kubernetes klasteris ar vismaz 4 vCPU un 8 GB RAM. Lai ātri iestatītu kopu un izpildītu rakstā sniegtos norādījumus, iesaku izmantot Google Cloud Platform, kas piedāvā jauniem lietotājiem bezmaksas 300 USD.

Pēc klastera izveides un piekļuves Kubernetes konfigurēšanas, izmantojot konsoles utilītu, varat instalēt Istio, izmantojot Helm pakotņu pārvaldnieku.

Stūres uzstādīšana

Instalējiet Helm klientu savā datorā, kā aprakstīts sadaļā oficiālā dokumentācija. Mēs to izmantosim, lai nākamajā sadaļā ģenerētu veidnes Istio instalēšanai.

Istio instalēšana

Lejupielādējiet Istio resursus no jaunākais izlaidums (sākotnējā autora saite uz versiju 1.0.5 ir nomainīta uz pašreizējo, t.i., 1.0.6 - apm. tulk.), izvelciet saturu vienā direktorijā, kuru turpmāk saukšu [istio-resources].

Lai viegli identificētu Istio resursus, izveidojiet nosaukumvietu K8s klasterī istio-system:

$ kubectl create namespace istio-system

Pabeidziet instalēšanu, dodoties uz direktoriju [istio-resources] un izpildiet komandu:

$ 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

Šī komanda failā izvadīs galvenos Istio komponentus istio.yaml. Mēs modificējām standarta veidni, lai tā atbilstu sev, norādot šādus parametrus:

global.mtls.enabled uzstādīts iekšā false (t.i., mTLS autentifikācija ir atspējota — apm.)lai vienkāršotu mūsu iepazīšanās procesu;
tracing.enabled ietver pieprasījumu izsekošanu, izmantojot Jaeger;
kiali.enabled instalē Kiali klasterī, lai vizualizētu pakalpojumus un trafiku;
grafana.enabled instalē Grafana, lai vizualizētu savāktos rādītājus.

Izmantosim ģenerētos resursus ar komandu:

$ kubectl apply -f istio.yaml

Istio instalēšana klasterī ir pabeigta! Pagaidiet, līdz visi podi ir nosaukumvietā istio-system varēs Running vai Completedizpildot tālāk norādīto komandu:

$ kubectl get pods -n istio-system

Tagad mēs esam gatavi turpināt darbu nākamajā sadaļā, kur mēs aktivizēsim lietojumprogrammu.

Sentimenta analīzes lietojumprogrammas arhitektūra

Izmantosim jau minētajā lietotās Sentiment Analysis mikropakalpojumu lietojumprogrammas piemēru Ievadraksts Kubernetes. Tas ir pietiekami sarežģīts, lai praksē parādītu Istio iespējas.

Lietojumprogramma sastāv no četriem mikropakalpojumiem:

Apkalpošana SA-Frontend, kas apkalpo Reactjs lietojumprogrammas priekšgalu;
Apkalpošana SA-WebApp, kas apkalpo noskaņojuma analīzes vaicājumus;
Apkalpošana SA-Logic, kas veic pati sentimenta analīze;
Apkalpošana SA-Atsauksmes, kas saņem atsauksmes no lietotājiem par analīzes precizitāti.

Šajā diagrammā papildus pakalpojumiem mēs redzam arī ieejas kontrolieri, kas Kubernetes maršrutē ienākošos pieprasījumus uz attiecīgajiem pakalpojumiem. Istio savā Ingress Gateway izmanto līdzīgu koncepciju, par kuru sīkāka informācija sekos.

Lietojumprogrammas palaišana ar starpniekserveri no Istio

Lai veiktu turpmākas rakstā minētās darbības, klonējiet savu repozitoriju istio-meistarība. Tas satur Kubernetes un Istio lietojumprogrammu un manifestus.

Blakusvāģu ievietošana

Ievietošanu var veikt automātiski vai ar rokām. Lai automātiski ievietotu blakusvāģa konteinerus, nosaukumvietai būs jāiestata etiķete istio-injection=enabled, kas tiek darīts ar šādu komandu:

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

Tagad katrs pods, kas tiks izvietots noklusējuma nosaukumvietā (default) saņems savu blakusvāģa konteineru. Lai to pārbaudītu, izvietosim testa lietojumprogrammu, dodoties uz repozitorija saknes direktoriju [istio-mastery] un palaižot šādu komandu:

$ 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

Pēc pakalpojumu izvietošanas pārbaudīsim, vai podiem ir divi konteineri (ar pašu pakalpojumu un tā blakusvāģi), izpildot komandu kubectl get pods un pārliecinoties, ka zem kolonnas READY norādītā vērtība 2/2, kas simbolizē, ka darbojas abi konteineri:

$ 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

Vizuāli tas izskatās šādi:

Sūtņa starpniekserveris vienā no podiem

Tagad, kad lietojumprogramma ir izveidota un darbojas, mums būs jāļauj ienākošajai trafikai ienākt lietojumprogrammā.

Ieejas vārteja

Labākā prakse, lai to panāktu (atļaut trafiku klasterī), ir cauri Ieejas vārteja Istio, kas atrodas klastera “malā” un ļauj iespējot Istio funkcijas, piemēram, maršrutēšanu, slodzes līdzsvarošanu, drošību un ienākošās trafika uzraudzību.

Istio instalēšanas laikā klasterī tika instalēts Ingress Gateway komponents un pakalpojums, kas to pārsūta ārēji. Lai uzzinātu pakalpojuma ārējo IP adresi, palaidiet:

$ 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

Mēs turpināsim piekļūt lietojumprogrammai, izmantojot šo IP (es to saukšu kā EXTERNAL-IP), tāpēc ērtības labad mēs ierakstīsim vērtību mainīgajā:

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

Ja mēģināsit piekļūt šim IP, izmantojot pārlūkprogrammu, jūs saņemsit kļūdu Pakalpojums nav pieejams, jo pēc noklusējuma Istio bloķē visu ienākošo trafiku, Vārteja vēl nav definēta.

Vārtejas resurss

Vārteja ir Kubernetes CRD (pielāgota resursu definīcija), kas definēta pēc Istio instalēšanas klasterī un dod iespēju norādīt portus, protokolu un saimniekdatorus, kuriem mēs vēlamies atļaut ienākošo trafiku.

Mūsu gadījumā mēs vēlamies atļaut HTTP trafiku 80. portā visiem saimniekiem. Uzdevums tiek īstenots ar šādu definīciju (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:
- "*"

Šai konfigurācijai nav nepieciešams paskaidrojums, izņemot selektoru istio: ingressgateway. Ar šo atlasītāju mēs varam norādīt, kurai ieejas vārtejai lietot konfigurāciju. Mūsu gadījumā tas ir Ingress Gateway kontrolleris, kas Istio tika instalēts pēc noklusējuma.

Konfigurācija tiek piemērota, izsaucot šādu komandu:

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

Tagad vārteja ļauj piekļūt 80. portam, taču tam nav ne jausmas, kur novirzīt pieprasījumus. Šim nolūkam jums būs nepieciešams Virtuālie pakalpojumi.

Virtuālā pakalpojuma resurss

Virtuālais pakalpojums norāda ieejas vārtejai, kā maršrutēt pieprasījumus, kas ir atļauti klasterī.

Pieprasījumi mūsu lietojumprogrammai, kas tiek saņemti, izmantojot http-gateway, ir jānosūta sa-frontend, sa-web-app un sa-feedback pakalpojumiem:

Maršruti, kas jākonfigurē, izmantojot VirtualServices

Apskatīsim pieprasījumus, kas jānosūta SA-Frontend:

Precīza sakritība pa ceļam / jānosūta uz SA-Frontend, lai iegūtu index.html;
Prefiksi ceļi /static/* jānosūta uz SA-Frontend, lai saņemtu priekšgalā izmantotos statiskos failus, piemēram, CSS un JavaScript;
Ceļi, kas atbilst regulārai izteiksmei '^.*.(ico|png|jpg)$', jānosūta uz SA-Frontend, jo Šie ir lapā redzamie attēli.

Ieviešana tiek panākta ar šādu konfigurāciju (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
Svarīgi punkti:

Šis virtuālais pakalpojums attiecas uz pieprasījumiem, kas tiek saņemti http-vārteja;
В destination Tiek noteikts pakalpojums, kuram tiek nosūtīti pieprasījumi.

Piezīme: iepriekš minētā konfigurācija tiek saglabāta failā sa-virtualservice-external.yaml, kas satur arī iestatījumus maršrutēšanai programmās SA-WebApp un SA-Feedback, taču īsuma labad tas šeit ir saīsināts.

Pieteiksim VirtualService, zvanot:

Piezīme: Kad mēs patērējam Istio resursus, Kubernetes API serveris izveido notikumu, ko saņem Istio vadības plakne, un pēc tam jaunā konfigurācija tiek lietota katra poda Envoy starpniekserveriem. Un Ingress Gateway kontrolleris, šķiet, ir vēl viens sūtnis, kas konfigurēts vadības plaknē. Diagrammā tas viss izskatās šādi:

Istio-IngressGateway konfigurācija pieprasījuma maršrutēšanai

Sentimenta analīzes lietojumprogramma tagad ir pieejama vietnē http://{EXTERNAL-IP}/. Neuztraucieties, ja saņemat statusu Nav atrasts: Dažreiz paiet nedaudz ilgāks laiks, līdz konfigurācija stājas spēkā un sūtņa kešatmiņas tiek atjauninātas.

Pirms turpināt, nedaudz spēlējiet ar lietotni, lai radītu trafiku. (tā klātbūtne ir nepieciešama skaidrības labad turpmākajās darbībās - apm. tulk.).

Kiali: novērojamība

Lai nokļūtu Kiali administratīvajā saskarnē, palaidiet šādu komandu:

... un atvērts http://localhost:20001/, piesakoties kā admin/admin. Šeit jūs atradīsiet daudzas noderīgas funkcijas, piemēram, lai pārbaudītu Istio komponentu konfigurāciju, vizualizētu pakalpojumus, izmantojot informāciju, kas savākta, pārtverot tīkla pieprasījumus, saņemtu atbildes uz jautājumiem “Kas ar ko sazinās?”, “Kura pakalpojuma versija ir pieejama. neveiksmes?” un tā tālāk. Vispārīgi izpētiet Kiali iespējas, pirms pāriet pie metrikas vizualizācijas ar Grafana.

Grafana: metrikas vizualizācija

Istio apkopotā metrika tiek iekļauta Prometheus un tiek vizualizēta ar Grafana. Lai piekļūtu Grafana administratīvajam interfeisam, palaidiet tālāk norādīto komandu un pēc tam atveriet http://localhost:3000/:

Noklikšķinot uz izvēlnes Sākumlapa augšējā kreisajā stūrī un atlasot Istio pakalpojumu informācijas panelis augšējā kreisajā stūrī sāciet ar apkalpošanu sa-web-applai apskatītu apkopotos rādītājus:

Šeit mūs sagaida tukša un pilnīgi garlaicīga izrāde - vadība to nekad neapstiprinās. Izveidosim nelielu slodzi ar šādu komandu:

Tagad mums ir daudz jaukāki grafiki un papildus tiem brīnišķīgi Prometheus rīki uzraudzībai un Grafana metrikas vizualizācijai, kas ļaus mums uzzināt par veiktspēju, veselību, pakalpojumu uzlabojumiem / pasliktināšanos laika gaitā.

Visbeidzot, apskatīsim pakalpojumu izsekošanas pieprasījumus.

Jēgers: izsekošana

Mums būs nepieciešama izsekošana, jo jo vairāk pakalpojumu mums ir, jo grūtāk ir atrast neveiksmes cēloni. Apskatīsim vienkāršu gadījumu no tālāk redzamā attēla:

Tipisks nejauša neveiksmīga pieprasījuma piemērs

Pieprasījums nāk, krīt - kāds ir iemesls? Pirmais serviss? Vai arī otrais? Abos ir izņēmumi – apskatīsim katra žurnālu. Cik bieži esat pieķēris sevi to darām? Mūsu darbs vairāk līdzinās programmatūras detektīviem, nevis izstrādātājiem...

Tā ir izplatīta problēma mikropakalpojumos, un to risina izkliedētās izsekošanas sistēmas, kurās pakalpojumi viens otram nodod unikālu galveni, pēc kura šī informācija tiek pārsūtīta uz izsekošanas sistēmu, kur tā tiek salīdzināta ar pieprasījuma datiem. Šeit ir ilustrācija:

TraceId tiek izmantots, lai identificētu pieprasījumu

Istio izmanto Jaeger Tracer, kas ievieš no pārdevēja neatkarīgu OpenTracing API ietvaru. Jaeger lietotāja interfeisam varat piekļūt ar šādu komandu:

Tagad dodieties uz http://localhost:16686/ un izvēlieties pakalpojumu sa-web-app. Ja pakalpojums netiek rādīts nolaižamajā izvēlnē, parādiet/ģenerējiet lapā darbību un atjauniniet saskarni. Pēc tam noklikšķiniet uz pogas Atrodiet pēdas, kurā būs redzamas jaunākās pēdas - atlasiet jebkuru - parādīsies detalizēta informācija par visām pēdām:

Šī pēda parāda:

Pieprasījums ienāk istio-ingressgateway (šī ir pirmā mijiedarbība ar vienu no pakalpojumiem, un pieprasījumam tiek ģenerēts izsekošanas ID), pēc kura vārteja nosūta pieprasījumu pakalpojumam sa-web-app.
Servisā sa-web-app pieprasījumu paņem sūtņa blakusvāģis, laidumā tiek izveidots “bērns” (tāpēc mēs to redzam pēdās) un novirzīts uz konteineru sa-web-app. (Sprīdis - loģiskā darba vienība Jēgerā, kurai ir nosaukums, operācijas sākuma laiks un ilgums. Laidumus var ligzdot un sakārtot. Virzīts aciklisks laidumu grafiks veido pēdu. — apm. tulk.)
Šeit pieprasījums tiek apstrādāts pēc metodes sentimenta analīze. Šīs pēdas jau ir ģenerētas lietojumprogrammā, t.i. viņiem bija nepieciešamas koda izmaiņas.
No šī brīža tiek uzsākts POST pieprasījums sa-loģika. Izsekošanas ID ir jāpārsūta no sa-web-app.
...

Piezīme: 4. darbībā lietojumprogrammai ir jāredz Istio ģenerētās galvenes un jānosūta tās nākamajiem pieprasījumiem, kā parādīts tālāk esošajā attēlā:

(A) Istio ir atbildīgs par galveņu pārsūtīšanu; (B) Pakalpojumi ir atbildīgi par galvenēm

Istio veic lielāko daļu darba, jo... ģenerē ienākošo pieprasījumu galvenes, katrā blakusaprūpē izveido jaunus posmus un pārsūta tos. Tomēr, nestrādājot ar galvenēm pakalpojumos, tiks zaudēts viss pieprasījuma izsekošanas ceļš.

Jāņem vērā šādas galvenes:

Tas nav sarežģīts uzdevums, taču, lai vienkāršotu tā ieviešanu, tas jau ir daudzas bibliotēkas - piemēram, sa-web-app pakalpojumā RestTemplate klients pārsūta šīs galvenes, ja jūs vienkārši pievienojat Jaeger un OpenTracing bibliotēkas viņa atkarības.

Ņemiet vērā, ka sentimentu analīzes lietojumprogramma demonstrē ieviešanu Flask, Spring un ASP.NET Core.

Tagad, kad ir skaidrs, ko mēs iegūstam no kastes (vai gandrīz no kastes), apskatīsim precīzi noregulētu maršrutēšanu, tīkla trafika pārvaldību, drošību utt.!

Piezīme. tulk.: Lasiet par to nākamajā Rinor Maloku materiālu par Istio daļā, kuru tulkojumi tuvākajā laikā tiks publicēti mūsu emuārā. UPDATE (14. marts): Otrā daļa jau ir publicēts.

PS no tulka

Lasi arī mūsu emuārā:

"Atpakaļ uz mikropakalpojumiem ar Istio": 2. daļa (maršrutēšana, satiksmes kontrole), 3. daļa (autentifikācija un autorizācija);
«Caurule - viegls Kubernetes servisa tīkls";
«Kas ir pakalpojumu tīkls un kāpēc tas ir vajadzīgs [mākoņa lietojumprogrammai ar mikropakalpojumiem]?";
«Ilustrēts ceļvedis Kubernetes tīkla izveidei. 1. un 2. daļa";
«Kā šis blakusvāģa konteiners nokļuva šeit [Kubernetes]?'.

Avots: www.habr.com

Atgriezties uz mikropakalpojumiem ar Istio. 1. daļa