Istioga tagasi mikroteenuste juurde. 1. osa

Märge. tõlge: Teenusvõrgud on tänapäeva mikroteenuste arhitektuuri järgivate rakenduste infrastruktuuris kindlasti muutunud kuumaks teemaks. Kuigi Istio võib olla paljude DevOpsi inseneride radaril, on tegemist üsna uue tootega, mille tundmaõppimiseks võib kuluda küll palju aega, kuigi see on pakutavate funktsioonide poolest keeruline. Saksa insener Rinor Maloku, kes vastutab telekommunikatsioonifirmas Orange Networks suurklientide pilvandmetöötluse eest, on kirjutanud suurepärase materjalisarja, mis võimaldab kiiresti ja sügavalt Istiosse sukelduda. Ta alustab oma lugu sellega, mida Istio suudab ja kuidas seda kiiresti oma silmaga näha.

Istio — avatud lähtekoodiga projekt, mis töötati välja koostöös Google'i, IBMi ja Lyfti meeskondadega. See lahendab keerukused, mis tekivad näiteks mikroteenustel põhinevates rakendustes, näiteks:

• liikluskorraldus: ajalõpud, korduskatsed, koormuse tasakaalustamine;
• turvalisus: lõppkasutaja autentimine ja autoriseerimine;
• jälgitavus: jälgimine, seire, metsaraie.

Neid kõiki saab lahendada rakenduse tasemel, kuid pärast seda ei ole teie teenused enam "mikro". Kõik lisapingutused nende probleemide lahendamiseks on ettevõtte ressursside raiskamine, mida saaks kasutada otse ärilise väärtuse teenimiseks. Kaaluge näidet:

Projektijuht: kui kaua võtab tagasiside funktsiooni lisamine aega?
Arendaja: kaks sprinti.

MP: Mida?.. See on lihtsalt TORE!
R: CRUD-i tegemine on ülesande lihtne osa, kuid me peame siiski kasutajaid ja teenuseid autentima ja autoriseerima. Kuna võrk on ebausaldusväärne, peate rakendama ka korduvaid taotlusi kaitselüliti muster klientides. Samuti veendumaks, et kogu süsteem kokku ei jooksnud, ajalõpud ja vaheseinad (Lisateavet mõlema mainitud mustri kohta leiate artiklist hiljem.)ning probleemide tuvastamiseks, jälgimiseks, jälgimiseks, […]

MP: Oh, paneme selle funktsiooni siis tooteteenusesse.

Arvan, et idee on selge: ühe teenuse lisamiseks on vaja palju samme ja jõupingutusi. Selles artiklis vaatleme, kuidas Istio eemaldab teenustest kogu ülalmainitud keerukuse (mitte äriloogikaga sihitud).

Märkus: artikkel eeldab, et teil on Kubernetesest tööalased teadmised. Muidu soovitan lugeda minu sissejuhatus Kubernetesesse ja alles siis jätkake selle materjali lugemist.

Istio idee

Ilma Istiota maailmas teeb üks teenus teisele otsepäringuid ja rikke korral peab teenus sellega ise hakkama saama: tegema uue katse, ette nägema ajalõpu, avama kaitselüliti jne.

Võrguliiklus Kubernetesis

Istio seevastu pakub spetsiaalset lahendust, mis on teenustest ja funktsioonidest täiesti eraldiseisev, segades võrgu suhtlust. Ja seega rakendab see:

• veataluvus: vastuses oleva olekukoodi põhjal saab ta aru, kas päring ebaõnnestus ja esitab selle uuesti.
• Canary Rollouts: suunab ainult kindla protsendi taotlustest teenuse uude versiooni.
• Seire ja mõõdikud: kui kaua kulus teenusel vastamiseks?
• Jälgimine ja jälgitavus: lisab igale päringule spetsiaalsed päised ja jälgib neid kogu klastris.
• turvalisus: hangib JWT märgi, autentib ja volitab kasutajaid.

Need on vaid mõned võimalused (tõesti vaid mõned!) teid intrigeerida. Nüüd sukeldume tehnilistesse üksikasjadesse!

Arhitektuur

Istio peatab kogu võrguliikluse ja rakendab sellele reegleid, lisades igasse moodulisse nutika puhverserveri külgkorvi konteineri kujul. Kõiki võimalusi aktiveerivad puhverserverid moodustavad a Andmetasandja neid saab dünaamiliselt reguleerida Juhtplaat.

Andmetasand

Kaunadesse sisestatavad puhverserverid võimaldavad Istiol hõlpsasti täita meile vajalikud nõuded. Näiteks kontrollime korduskatseid ja kaitselülitite funktsioone.

Kuidas on Envoy's rakendatud korduskatseid ja voolukatkestusi

Kokkuvõtteks:

1. saadik (Jutt käib külgkorvi konteineris asuvast puhverserverist, mida jagatakse ja kuidas eraldi toode - u. tõlge.) saadab päringu teenuse B esimesele eksemplarile ja ebaõnnestub.
2. Saadik külgkorvi proovib uuesti (uuesti proovima). (1)
3. Ebaõnnestunud päring tagastatakse sellele kutsunud puhverserverile.
4. See avab kaitselüliti ja helistab järgmiste taotluste jaoks järgmisele teenusele. (2)

See tähendab, et te ei pea kasutama järgmist uuesti proovimise teeki, te ei pea ise juurutama Circuit Breaking ja Service Discovery programmeerimiskeeles X, Y või Z. Kõik see ja palju muud on saadaval kast Istios ja ei nõua ei koodi muutused.

Suurepärane! Nüüd võib tekkida soov minna Istioga merereisile, kuid kahtlusi, lahtisi küsimusi on veel. Kui see on universaalne lahendus kõigiks elujuhtumiteks, siis on teil õigustatud kahtlus: kõik sellised lahendused ei sobi ju tegelikult ühegi juhtumi jaoks.

Ja lõpuks küsite: "Kas see on kohandatav?"

Nüüd olete merereisiks valmis – ja tutvume Control Plane’iga.

Juhtplaat

See koosneb kolmest komponendist: Piloot, Mikser и Kants, mis koos konfigureerivad saadikud liikluse suunamiseks, poliitikate jõustamiseks ja telemeetriaandmete kogumiseks. Skemaatiliselt näeb see kõik välja selline:

Juhttasandi ja andmetasandi koostoime

Saatjad (st andmetasand) on konfigureeritud Kubernetes CRD (Kohandatud ressursside määratlused), mille Istio on määratlenud ja spetsiaalselt selleks otstarbeks loodud. See tähendab teie jaoks seda, et need on lihtsalt veel üks tuttava süntaksiga Kubernetese ressurss. Pärast loomist võtab juhttasand selle ressursi üles ja rakendab saadikutele.

Teenuste seos Istioga

Oleme kirjeldanud Istio suhet teenustega, kuid mitte vastupidi: kuidas on teenused seotud Istioga?

Ausalt öeldes teavad talitused Istio olemasolust sama hästi kui kalad veest, kui küsivad endalt: “Mis on ikkagi vesi?”.

Joonis Victoria Dimitrakopoulos: Kuidas sulle vesi meeldib? - Mis on ikkagi vesi?

Seega võite võtta töötava klastri ja pärast Istio komponentide juurutamist jätkavad selles olevad teenused tööd ning pärast nende komponentide eemaldamist on kõik jälle korras. Selge on see, et sel juhul jääd ilma Istio pakutavatest võimalustest.

Aitab teooriast – paneme need teadmised ellu!

Istio praktikas

Istio vajab Kubernetese klastrit, millel on vähemalt 4 vCPU-d ja 8 GB muutmälu. Klastri kiireks tõstmiseks ja artikli juhiste järgimiseks soovitan kasutada Google Cloud Platformi, mis pakub uutele kasutajatele tasuta 300 dollarit.

Pärast klastri loomist ja konsooliutiliidi kaudu Kubernetesele juurdepääsu seadistamist saate installida Istio Helmi paketihalduri kaudu.

Helmi paigaldamine

Installige Helmi klient oma arvutisse, nagu on kirjeldatud jaotises ametlik dokumentatsioon. Kasutame seda järgmises jaotises Istio installimiseks mallide loomiseks.

Paigaldamine

Laadige alla Istio ressursid aadressilt uusim väljalase (algse autori link versioonile 1.0.5 on muudetud praeguseks, st 1.0.6 - umbes tõlge.), eraldage sisu ühte kataloogi, mida ma nimetan [istio-resources].

Istio ressursside hõlpsaks tuvastamiseks looge K8s klastris nimeruum istio-system:

$ kubectl create namespace istio-system

Viige installimine lõpule, navigeerides kataloogi [istio-resources] ja käivitage käsk:

$ 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

See käsk väljastab Istio põhikomponendid faili istio.yaml. Oleme standardmalli enda jaoks muutnud, määrates järgmised parameetrid:

• global.mtls.enabled sisse paigaldatud false (st mTLS-i autentimine on keelatud – ligikaudu tõlge)meie tutvumisprotsessi lihtsustamiseks;
• tracing.enabled võimaldab Jaegeriga päringu jälgimist;
• kiali.enabled installib Kiali teenuste ja liikluse visualiseerimiseks klastrisse;
• grafana.enabled installib Grafana kogutud mõõdikute visualiseerimiseks.

Rakendage loodud ressursse käsuga:

$ kubectl apply -f istio.yaml

Istio paigaldamine klastris on lõppenud! Oodake, kuni kõik nimeruumis olevad kaustad istio-system suudab Running või Completedkäivitades alloleva käsu:

$ kubectl get pods -n istio-system

Nüüd oleme valmis jätkama järgmise jaotisega, kus tõstame rakenduse üles ja käivitame.

Sentiment Analysis Application Architecture

Kasutame juba mainitud juures kasutatud Sentiment Analysis mikroteenuse rakenduse näidet Kubernetese tutvustusartikkel. See on piisavalt keeruline, et näidata Istio võimalusi praktikas.

Rakendus koosneb neljast mikroteenusest:

1. Teenus SA-Eesmine, mis teenindab Reactjs'i esiotsa rakendust;
2. Teenus SA WebApp, mis teenindab Sentiment Analysis päringuid;
3. Teenus SA loogikamis täidab ennast sentiment analüüs;
4. Teenus SA tagasiside, mis saab kasutajatelt tagasisidet tehtud analüüsi täpsuse kohta.

Sellel diagrammil näeme lisaks teenustele ka sissepääsukontrollerit, mis Kubernetes suunab sissetulevad päringud vastavatele teenustele. Istio kasutab sarnast kontseptsiooni Ingress Gateway osana, mille üksikasjad järgnevad.

Rakenduse käivitamine Istio puhverserveriga

Artiklis mainitud edasiste toimingute jaoks kloonige oma hoidla istio-meisterlikkus. See sisaldab rakendust ja manifeste Kubernetese ja Istio jaoks.

Külgkorvide paigaldamine

Sisestamist saab teha automaatselt või käsitsi. Külgkorvi konteinerite automaatseks sisestamiseks peate määrama sildi nimeruumile istio-injection=enabled, mis tehakse järgmise käsuga:

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

Nüüd iga pod, mis juurutatakse vaikenimeruumi (default) saab oma külgkorvi konteineri. Selle kontrollimiseks juurutagem testrakendus, minnes hoidla juurkataloogi [istio-mastery] ja käivitage järgmine käsk:

$ 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ärast teenuste juurutamist kontrollige käsu käivitamisega, et kaustadel oleks kaks konteinerit (koos teenuse enda ja selle külgkorviga) kubectl get pods ja veenduge, et veeru all READY määratud väärtus 2/2, mis sümboliseerib, et mõlemad konteinerid töötavad:

$ 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

Visuaalselt näeb see välja selline:

Saatja volikiri ühes kaunadest

Nüüd, kui rakendus on käivitatud ja töötab, peame lubama sissetuleval liiklusel rakendusse siseneda.

Sissepääsu värav

Parim tava selle saavutamiseks (liikluse lubamine klastris) on läbimine Sissepääsu värav Istios, mis asub klastri servas ja võimaldab lubada Istio funktsioone, nagu marsruutimine, koormuse tasakaalustamine, turvalisus ja sissetuleva liikluse jälgimine.

Ingress Gateway komponent ja teenus, mis seda väljapoole edastab, installiti klastris Istio installimise ajal. Teenuse välise IP-aadressi väljaselgitamiseks käivitage:

$ 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

Jätkame rakendusele juurdepääsu selle IP-aadressiga (ma nimetan seda VÄLIS-IP-ks), nii et mugavuse huvides kirjutame väärtuse muutujale:

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

Kui proovite sellele IP-le nüüd brauseri kaudu juurde pääseda, kuvatakse tõrketeade Teenus pole saadaval, kuna vaikimisi blokeerib Istio kogu sissetuleva liiklusekuni lüüs on määratletud.

Lüüsi ressurss

Gateway on Kubernetes CRD (kohandatud ressursi definitsioon), mis defineeritakse pärast Istio installimist klastris ja võimaldab määrata pordid, protokollid ja hostid, mille jaoks tahame sissetulevat liiklust lubada.

Meie puhul tahame lubada HTTP-liiklust pordis 80 kõikidele hostidele. Probleem on realiseeritud järgmise definitsiooniga (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:
- "*"

See konfiguratsioon ei vaja selgitust peale valija istio: ingressgateway. Selle valijaga saame määrata, millisele sissepääsulüüsile konfiguratsiooni rakendada. Meie puhul on selleks Ingress Gateway kontroller, mis installiti vaikimisi Istiosse.

Konfiguratsiooni rakendatakse järgmise käsu kutsumisega:

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

Lüüs võimaldab nüüd juurdepääsu pordile 80, kuid tal pole aimugi, kuhu päringud suunata. Selleks vajate Virtuaalsed teenused.

Virtuaalteenuse ressurss

VirtualService ütleb sisendlüüsile, kuidas suunata klastris lubatud päringuid.

Meie rakendusele http-lüüsi kaudu tulevad taotlused tuleb saata sa-frontendi, sa-web-app ja sa-tagasiside teenustele:

VirtualServicesiga konfigureeritavad marsruudid

Mõelge päringutele, mis tuleks SA-Frontendile saata:

• Täpne vaste teel / tuleks saata SA-Frontendile, et saada index.html;
• Eesliitega teed /static/* tuleks saata SA-Frontendile, et saada kasutajaliideses kasutatavaid staatilisi faile, nagu CSS ja JavaScript;
• Regulaaravaldisele vastavad teed '^.*.(ico|png|jpg)$', tuleb saata SA-Frontendile, sest Need on lehel kuvatavad pildid.

Rakendamine saavutatakse järgmise konfiguratsiooniga (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

Olulised märkused:

 See virtuaalteenus viitab päringutele, mis tulevad läbi http-lüüs;
 В destination määrab teenuse, kuhu päringud saadetakse.

Märkus: ülaltoodud konfiguratsioon salvestatakse faili sa-virtualservice-external.yaml, mis sisaldab ka SA-WebAppi ja SA-Feedbacki marsruutimise sätteid, kuid on siin artiklis lühiduse huvides lühendatud.
Taotlege VirtualService'i helistades:

Märkus: Istio ressursside rakendamisel käivitab Kubernetes API server sündmuse, mille Istio juhtimistasand vastu võtab, ja pärast seda rakendatakse uut konfiguratsiooni iga podi Envoy puhverserveritele. Ja Ingress Gateway kontroller näib olevat veel üks juhttasandil konfigureeritud saadik. Kõik see näeb diagrammil välja selline:


Istio-IngressGateway konfiguratsioon päringu marsruutimiseks
Sentiment Analysis on nüüd saadaval aadressil http://{EXTERNAL-IP}/. Ärge muretsege, kui saate oleku Ei leitud: mõnikord kulub konfiguratsiooni jõustumiseks ja Envoy vahemälu värskendamiseks veidi kauem aega.
Enne jätkamist mängige liikluse tekitamiseks veidi rakendusega. (selle olemasolu on vajalik selguse huvides järgnevates toimingutes - umbes tõlge).
Kiali : jälgitavus
Kiali administraatoriliidese juurde pääsemiseks käivitage järgmine käsk:

… ja avage http://localhost:20001/logides sisse kui admin/admin. Siit leiate palju kasulikke funktsioone, näiteks saate kontrollida Istio komponentide konfiguratsiooni, visualiseerida teenuseid võrgupäringute pealtkuulamisel kogutud teabe põhjal, saada vastuseid küsimustele "Kes kellega ühendust võtab?", "Milline teenuse versioon on kasutusel ebaõnnestumised?" ja nii edasi. Üldiselt uurige Kiali võimalusi, enne kui asute Grafana abil mõõdikute visualiseerimisele.

Grafana: mõõdikute visualiseerimine
Istios kogutud mõõdikud jõuavad Prometheusesse ja visualiseeritakse Grafana abil. Grafana administraatoriliidese avamiseks käivitage allolev käsk ja seejärel avage http://localhost:3000/:

Menüüle klõpsates Avaleht üleval vasakul ja valige Istio teenuse juhtpaneel vasakus ülanurgas alustage teenindusega sa-veebirakenduskogutud mõõdikute vaatamiseks:

Siin ootame tühja ja täiesti igavat esinemist – juhtkond ei kiida seda kunagi heaks. Loome väikese koormuse järgmise käsuga:

Nüüd on meil palju ilusamad graafikud ja lisaks neile suurepärased tööriistad Prometheus jälgimiseks ja Grafana mõõdikute visualiseerimiseks, mis võimaldavad meil õppida jõudluse, tervisliku seisundi, teenuste paranemise / halvenemise kohta aja jooksul.
Lõpuks vaatame päringu jälgimist teenustes.
Jaeger: jälitamine
Vajame jälgimist, sest mida rohkem teenuseid meil on, seda keerulisem on rikke põhjuseni jõuda. Vaatame lihtsat juhtumit allolevalt pildilt:


Tüüpiline näide juhuslikust ebaõnnestunud päringust
Palve tuleb, kukub - mis on põhjus? Esimene teenindus? Või teiseks? Mõlemas on erandeid – vaatame kummagi logisid. Kui sageli olete end seda tegemas tabanud? Meie töö on rohkem nagu tarkvara detektiivid kui arendajad…
See on mikroteenustes laialt levinud probleem ja seda lahendavad hajutatud jälgimissüsteemid, milles teenused edastavad üksteisele kordumatu päise, misjärel see teave suunatakse jälgimissüsteemi, kus seda võrreldakse päringu andmetega. Siin on illustratsioon:


TraceId kasutatakse päringu tuvastamiseks
Istio kasutab Jaeger Tracerit, mis rakendab müüjast sõltumatut OpenTracing API raamistikku. Jaegeri kasutajaliidesele pääsete juurde järgmise käsuga:

Nüüd minge juurde http://localhost:16686/ ja valige teenus sa-veebirakendus. Kui teenust rippmenüüs ei kuvata, kuvage/genereerige lehel tegevust ja värskendage liidest. Pärast seda klõpsake nuppu Leia jälgi, mis näitab kõige värskemaid jälgi - valige ükskõik milline - kuvatakse üksikasjalik teave kõigi jälgede kohta:

See jälg näitab:

 Taotlus tuleb sisse istio-sissepääsuvärav (see on esimene interaktsioon ühe teenusega ja päringu jaoks genereeritakse jälituse ID), mille järel lüüs saadab teenusele päringu sa-veebirakendus.
 Teenistuses sa-veebirakendus palve võtab üles Envoy külgkorvi, vahele luuakse "laps" (seetõttu näeme seda jälgedes) ja suunatakse konteinerisse sa-veebirakendus. (sille - loogiline tööüksus Jäägeris, millel on nimi, operatsiooni algusaeg ja kestus. Sirgesid saab pesastada ja järjestada. Suunatud atsükliline ulatuste graafik moodustab jälje. - u. tõlge.)
 Siin töödeldakse taotlust meetodil sentimentanalüüs. Need jäljed on juba rakenduse poolt genereeritud, st. nad nõudsid koodi muutmist.
 Sellest hetkest algatatakse POST-i päring sa-loogika. Jälje ID tuleb edastada aadressilt sa-veebirakendus.
 ...

Märkus: 4. sammus peaks rakendus nägema Istio loodud päiseid ja edastama need järgmistele päringutele, nagu on näidatud alloleval pildil:


(A) Päise edastamise eest vastutab Istio; (B) Päiste eest vastutavad teenused
Istio teeb suurema osa tööst, sest genereerib sissetulevate päringute päised, loob igas kõrvalhoolduses uued vahemikud ja edastab need. Kuid ilma teenuste sees päistega töötamata läheb kogu päringu jälgimise tee kaotsi.
Arvesse tuleb võtta (edasida) järgmisi päiseid:

See on lihtne ülesanne, kuid selle rakendamise lihtsustamiseks on see juba olemas palju raamatukogusid - näiteks sa-web-app teenuses saadab RestTemplate klient need päised edasi, kui lisate lihtsalt Jaegeri ja OpenTracingu teegid selle sõltuvused.
Pange tähele, et sentiment Analysis rakendus demonstreerib rakendusi Flaskis, Springis ja ASP.NET Core'is.
Nüüd, kui on selge, mida me karbist (või peaaegu kastist välja) saame, vaatame marsruutimise, võrguliikluse haldamise, turvalisuse ja palju muud täppishäälestust!
Märge. tõlge: selle kohta loe Rinor Maloku Istio materjalide järgmisest osast, mille tõlked on lähiajal ka meie blogis. UPDATE (14. märts): Teine osa juba avaldatud.
PS tõlkijalt
Loe ka meie blogist:

 "Tagasi mikroteenuste juurde Istioga": 2. osa (marsruutimine, liikluskorraldus), 3. osa (autentimine ja autoriseerimine);
 «Kanal – Kubernetese kerge hooldusvõrk";
 «Mis on teenindusvõrk ja miks ma seda vajan [mikroteenustega pilverakenduse jaoks]?";
 «Illustreeritud juhend Kubernetese võrgu loomiseks. 1. ja 2. osa";
 «Kuidas see külgkorvi konteiner siia [Kubernetesesse] sattus?'.

Allikas: www.habr.com