Aftur í örþjónustur með Istio. 1. hluti

Athugið. þýð.: Þjónustunet hafa örugglega orðið viðeigandi lausn í nútíma innviðum fyrir forrit sem fylgja örþjónustuarkitektúr. Þó að Istio gæti verið á ratsjá margra DevOps verkfræðinga, þá er það nokkuð ný vara sem, þó að hún sé flókin hvað varðar eiginleika sem hún býður upp á, getur tekið talsverðan tíma að kynnast henni. Þýski verkfræðingurinn Rinor Maloku, sem ber ábyrgð á tölvuskýi fyrir stóra viðskiptavini hjá fjarskiptafyrirtækinu Orange Networks, hefur skrifað dásamlega röð af efnum sem gerir þér kleift að kafa hratt og djúpt inn í Istio. Hann byrjar sögu sína á því hvað Istio getur gert almennt og hvernig þú getur fljótt séð það með eigin augum.

Sama — Open Source verkefni þróað í samvinnu við teymi frá Google, IBM og Lyft. Það leysir margbreytileikann sem kemur upp í forritum sem byggjast á örþjónustu, til dæmis, eins og:

• umferðarstjórnun: tímamörk, endurtilraunir, álagsjöfnun;
• öryggi: Auðkenning og heimild notenda;
• sjáanleika: rekja, eftirlit, skógarhögg.

Allt þetta er hægt að leysa á umsóknarstigi, en eftir það verður þjónusta þín ekki lengur „ör“. Öll auka viðleitni til að leysa þessi vandamál er sóun á auðlindum fyrirtækisins sem hægt væri að nota beint fyrir viðskiptaverðmæti. Lítum á dæmi:

Verkefnastjóri: Hversu langan tíma tekur það að bæta við endurgjöfareiginleika?
Hönnuður: Tveir sprettir.

þingmaður: Hvað?.. Þetta er bara CRUD!
R: Að gera CRUD er auðveldi hluti verkefnisins, en við þurfum samt að auðkenna og heimila notendur og þjónustu. Þar sem netið er óáreiðanlegt þarftu að innleiða endurteknar beiðnir, sem og mynstur aflrofa hjá viðskiptavinum. Einnig til að tryggja að allt kerfið hrundi ekki, tímamörk og þil (Sjá síðar í greininni fyrir frekari upplýsingar um bæði nefnd mynstur.), og til að greina vandamál, fylgjast með, rekja, […]

þingmaður: Æ, við skulum þá bara setja þennan eiginleika inn í vöruþjónustuna.

Ég held að hugmyndin sé skýr: magn skrefa og fyrirhafnar sem þarf til að bæta við einni þjónustu er gríðarlegt. Í þessari grein munum við skoða hvernig Istio fjarlægir allt flókið sem nefnt er hér að ofan (ekki miðað við viðskiptarökfræði) úr þjónustu.

Athugið: Greinin gerir ráð fyrir að þú hafir þekkingu á Kubernetes. Annars mæli ég með lestri kynning mín á Kubernetes og aðeins þá halda áfram að lesa þetta efni.

Istio hugmynd

Í heimi án Istio gerir ein þjónusta beinar beiðnir til annarrar og ef bilun kemur upp verður þjónustan að sjá um hana sjálf: gera nýja tilraun, gefa út tímamörk, opna aflrofa o.s.frv.

Netumferð í Kubernetes

Istio býður upp á sérhæfða lausn, algjörlega aðskilin frá þjónustu og virkni með því að trufla netsamskipti. Og þannig útfærir það:

• bilanaþol: byggt á stöðukóðanum í svarinu, skilur það hvort beiðnin mistókst og sendir hana aftur.
• Kanaríútrásir: vísar aðeins ákveðnu hlutfalli beiðna í nýju útgáfuna af þjónustunni.
• Vöktun og mælingar: Hvað leið langur tími fyrir þjónustuna að svara?
• Rekja og athugun: Bætir sérstökum hausum við hverja beiðni og rekur þá yfir þyrpinguna.
• öryggi: Sækir JWT tákn, auðkennir og heimilar notendur.

Þetta eru aðeins nokkrir möguleikar (í raun bara nokkrir!) til að vekja áhuga þinn. Nú skulum við kafa ofan í tæknilegu smáatriðin!

Istio arkitektúr

Istio hlerar alla netumferð og beitir setti reglna á hana og setur snjall proxy í formi hliðarvagnsíláts í hvern pod. Umboð sem virkja alla möguleika mynda a Gagnaflugvél, og hægt er að stilla þær á virkan hátt með því að nota Stýringarflugvél.

Gagnaflugvél

Umboð sem sett er inn í belg gerir Istio kleift að uppfylla þær kröfur sem við þurfum auðveldlega. Við skulum til dæmis athuga virkni aftur og aflrofa.

Hvernig endurtilraunir og rafrásarrofa eru útfærðar í Envoy

Til að draga saman:

1. Sendiherra (við erum að tala um umboð sem staðsett er í hliðarvagni, sem er dreift sem aðskilda vöru - ca. þýðing.) sendir beiðni til fyrsta aðila þjónustu B og mistekst.
2. Envoy Sidecar er að reyna aftur (reyna aftur). (1)
3. Misheppnuð beiðni er skilað til umboðsins sem kallaði hana.
4. Þetta opnar Circuit Breaker og hringir í næstu þjónustu fyrir síðari beiðnir. (2)

Þetta þýðir að þú þarft ekki að nota næsta Rery bókasafn, þú þarft ekki að gera þína eigin útfærslu á Circuit Breaking and Service Discovery á X, Y eða Z forritunarmálinu. Allt þetta og fleira er fáanlegt úr kassa í Istio og þarf ekki ekki kóða breytingar.

Frábært! Nú gætirðu viljað fara í sjóferð með Istio, en það eru enn einhverjar efasemdir, opnar spurningar. Ef þetta er allsherjarlausn fyrir öll tækifæri í lífinu, þá hefur þú réttmætan grun: Þegar öllu er á botninn hvolft eru allar slíkar lausnir í raun ekki við hæfi í öllum tilfellum.

Og að lokum spyrðu: "Er það sérsniðið?"

Nú ertu tilbúinn í sjóferð - og við skulum kynnast Control Plane.

Stýringarflugvél

Það samanstendur af þremur hlutum: Pilot, Hrærivél и Citadel, sem saman stilla sendimenn til að beina umferð, beita stefnum og safna fjarmælingagögnum. Skipulega lítur þetta allt svona út:

Samspil stjórnunarplans við gagnaplans

Sendimenn (þ.e. gagnaplan) eru stilltir með Kubernetes CRD (Custom Resource Definitions) skilgreind af Istio og sérstaklega hönnuð í þessum tilgangi. Það sem þetta þýðir fyrir þig er að þeir eru bara enn ein auðlindin í Kubernetes með kunnuglega setningafræði. Þegar það hefur verið búið til verður þetta úrræði tekið upp af stjórnflugvélinni og beitt til sendimanna.

Tengsl þjónustu við Istio

Við höfum lýst sambandi Istio við þjónustu, en ekki öfugt: hvernig tengist þjónusta Istio?

Satt að segja er þjónusta jafn meðvituð um nærveru Istio og fiskur um vatn þegar þeir spyrja sig: "Hvað er vatn eiginlega?"

Myndskreyting Viktoría Dimitrakopoulos: Hvernig líkar þér við vatnið? - Hvað er vatn eiginlega?

Þannig geturðu tekið virkan klasa og eftir að Istio íhlutunum hefur verið dreift mun þjónustan í honum halda áfram að virka og eftir að hafa fjarlægt þessa íhluti verður allt í lagi aftur. Það er ljóst að í þessu tilfelli muntu tapa þeim tækifærum sem Istio gefur.

Nóg af kenningum - við skulum koma þessari þekkingu í framkvæmd!

Istio í reynd

Istio krefst Kubernetes þyrpingar með að minnsta kosti 4 vCPU og 8 GB af vinnsluminni tiltækt. Til að hækka klasann fljótt og fylgja leiðbeiningunum úr greininni mæli ég með því að nota Google Cloud Platform, sem býður upp á nýja notendur ókeypis $300.

Eftir að hafa búið til þyrping og stillt aðgang að Kubernetes í gegnum stjórnborðsforritið geturðu sett upp Istio í gegnum Helm pakkastjórann.

Uppsetning hjálms

Settu upp Helm biðlarann ​​á tölvunni þinni eins og lýst er í opinber skjöl. Við munum nota þetta til að búa til sniðmát til að setja upp Istio í næsta kafla.

Er að setja upp Istio

Sækja Istio auðlindir frá nýjasta útgáfan (Tengill upprunalega höfundarins á útgáfu 1.0.5 hefur verið breytt í núverandi, þ.e. 1.0.6 - u.þ.b. þýðing), draga innihaldið í eina möppu, sem ég mun vísa til sem [istio-resources].

Til að auðkenna Istio auðlindir skaltu búa til nafnrými í K8s klasanum istio-system:

$ kubectl create namespace istio-system

Ljúktu við uppsetninguna með því að fara í möppuna [istio-resources] og keyra skipunina:

$ 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

Þessi skipun mun gefa út lykilhluti Istio í skrá istio.yaml. Við höfum breytt staðlaða sniðmátinu fyrir okkur með því að tilgreina eftirfarandi breytur:

• global.mtls.enabled sett upp í false (þ.e. mTLS auðkenning er óvirk - u.þ.b.)til að einfalda stefnumótaferli okkar;
• tracing.enabled felur í sér rekja beiðni með Jaeger;
• kiali.enabled setur Kiali upp í klasa til að sjá þjónustu og umferð;
• grafana.enabled setur upp Grafana til að sjá söfnuð mæligildi.

Notaðu tilföngin sem myndast með skipuninni:

$ kubectl apply -f istio.yaml

Uppsetningu Istio á klasanum er lokið! Bíddu þar til allir belgirnir eru í nafnarýminu istio-system mun geta Running eða Completedmeð því að keyra skipunina hér að neðan:

$ kubectl get pods -n istio-system

Nú erum við tilbúin til að halda áfram í næsta kafla, þar sem við munum koma forritinu í gang.

Viðhorfsgreining umsóknararkitektúr

Við skulum nota dæmið um Sentiment Analysis örþjónustuforritið sem notað var í áðurnefndu Kynningargrein um Kubernetes. Það er nógu flókið til að sýna getu Istio í reynd.

Forritið samanstendur af fjórum örþjónustum:

1. Service SA-Frontend, sem þjónar framenda Reactjs forrits;
2. Service SA WebApp, sem þjónar fyrirspurnum um tilfinningagreiningu;
3. Service SA rökfræðisem framkvæmir sig sjálft tilfinningagreiningu;
4. Service SA Feedback, sem fær endurgjöf frá notendum um nákvæmni greiningarinnar.

Á þessari skýringarmynd, auk þjónustu, sjáum við einnig Ingress Controller, sem í Kubernetes beinir innkomnum beiðnum til samsvarandi þjónustu. Istio notar svipað hugtak sem hluta af Ingress Gateway, upplýsingar um það munu fylgja.

Keyrir forrit með proxy frá Istio

Fyrir frekari aðgerðir sem getið er um í greininni, klónaðu geymsluna þína istio-stjórn. Það inniheldur forritið og upplýsingaskrá fyrir Kubernetes og Istio.

Að setja hliðarvagna í

Hægt er að setja inn sjálfkrafa eða með hendi. Til að setja hliðarvagnsílát sjálfkrafa inn þarftu að setja merkimiða á nafnrýmið istio-injection=enabled, sem er gert með eftirfarandi skipun:

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

Nú er hver fræbelgur sem verður settur í sjálfgefna nafnrýmið (default) fær hliðarvagn sinn. Til að staðfesta þetta skulum við setja upp prófunarforrit með því að fara í rótarskrá geymslunnar [istio-mastery] og keyra eftirfarandi skipun:

$ 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

Eftir að hafa dreift þjónustunni skulum við athuga hvort belgirnir séu með tvo ílát (með þjónustunni sjálfri og hliðarvagni hennar) með því að keyra skipunina kubectl get pods og ganga úr skugga um að undir dálkinum READY gildi tilgreint 2/2, sem táknar að báðir gámarnir séu í gangi:

$ 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

Sjónrænt lítur þetta svona út:

Sendiboði í einum af belgjunum

Nú þegar forritið er komið í gang þurfum við að leyfa komandi umferð að komast inn í forritið.

Ingress Gateway

Besta aðferðin til að ná þessu (leyfa umferð í klasanum) er í gegn Ingress Gateway í Istio, sem er staðsett við „brún“ klasans og gerir þér kleift að virkja Istio eiginleika eins og leið, álagsjafnvægi, öryggi og eftirlit með komandi umferð.

Ingress Gateway hluti og þjónustan sem sendir hann út var settur upp á þyrpingunni meðan á Istio uppsetningunni stóð. Til að komast að ytri IP tölu þjónustunnar skaltu keyra:

$ 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

Við munum halda áfram að fá aðgang að forritinu með því að nota þessa IP (ég mun vísa til þess sem EXTERNAL-IP), svo til hægðarauka munum við skrifa gildið í breytu:

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

Ef þú reynir að fá aðgang að þessari IP-tölu í gegnum vafra núna færðu villuna Þjónusta ekki tiltæk vegna þess sjálfgefið Istio lokar fyrir alla komandi umferð, Gátt hefur ekki enn verið skilgreint.

Gateway auðlind

Gateway er CRD (Custom Resource Definition) í Kubernetes, skilgreint eftir að Istio hefur verið sett upp í þyrpingunni og gerir möguleika á að tilgreina höfn, samskiptareglur og vélar sem við viljum leyfa komandi umferð fyrir.

Í okkar tilviki viljum við leyfa HTTP umferð á höfn 80 fyrir alla gestgjafa. Vandamálið er ljóst með eftirfarandi skilgreiningu (http-gátt.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:
- "*"

Þessi uppsetning þarfnast engrar skýringar nema fyrir veljarann istio: ingressgateway. Með þessu vali getum við tilgreint hvaða Ingress Gateway á að nota stillinguna á. Í okkar tilviki er þetta Ingress Gateway stjórnandi, sem var sjálfgefið settur upp í Istio.

Stillingunni er beitt með því að kalla eftirfarandi skipun:

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

Gáttin leyfir nú aðgang að port 80, en hefur ekki hugmynd um hvert á að beina beiðnum. Fyrir þetta þarftu Sýndarþjónusta.

VirtualService auðlind

Sýndarþjónustan segir Ingress Gateway hvernig á að beina beiðnum sem eru leyfðar innan klasans.

Beiðnir um umsókn okkar sem koma í gegnum http-gátt verða að sendast til sa-frontend, sa-web-app og sa-feedback þjónustunnar:

Leiðir sem á að stilla með VirtualServices

Við skulum skoða þær beiðnir sem ætti að senda til SA-Frontend:

• Nákvæm samsvörun í leiðinni / ætti að senda á SA-Frontend til að fá index.html;
• Slóðir með forskeyti /static/* ætti að senda til SA-Frontend til að fá fastar skrár notaðar í framendanum, svo sem CSS og JavaScript;
• Slóðir sem passa við reglubundna tjáningu '^.*.(ico|png|jpg)$', verður að senda SA-Frontend, vegna þess Þetta eru myndirnar sem birtast á síðunni.

Framkvæmdinni er náð með eftirfarandi uppsetningu (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

Mikilvæg atriði:

 Þessi sýndarþjónusta vísar til beiðna sem berast http-gátt;
 В destination Ákvörðuð er til hvaða þjónustu beiðnir eru sendar.

Athugið: Uppsetningin hér að ofan er geymd í skrá sa-virtualservice-external.yaml, sem einnig inniheldur stillingar fyrir leið til SA-WebApp og SA-Feedback, en hefur verið stytt hér í greininni til að vera stutt.
Notum VirtualService með því að hringja í:

Athugið: Þegar við neytum Istio auðlinda, býr Kubernetes API Server til atburð sem er móttekin af Istio Control Plane, og eftir það er nýju stillingunum beitt á sendiboða umboðsmanna hvers fræbelgs. Og Ingress Gateway stjórnandi virðist vera annar sendimaður sem er stilltur í stjórnplaninu. Allt lítur þetta svona út á skýringarmyndinni:


Istio-IngressGateway stillingar fyrir beiðni um beiðni
Sentiment Analysis forrit er nú fáanlegt á http://{EXTERNAL-IP}/. Ekki hafa áhyggjur ef þú færð Not Found stöðu: stundum tekur það aðeins lengri tíma fyrir uppsetninguna að taka gildi og fyrir sendiforritið að uppfæra.
Áður en þú heldur áfram skaltu leika þér aðeins með forritið til að búa til umferð (Návist þess er nauðsynleg til skýrleika í síðari aðgerðum - u.þ.b. þýðing).
Kiali: sjáanleiki
Til að komast í Kiali admin tengi skaltu keyra eftirfarandi skipun:

... og opna http://localhost:20001/með því að skrá þig inn sem admin/admin. Hér finnur þú marga gagnlega eiginleika, til dæmis til að kanna stillingar Istio íhluta, sjá þjónustu með því að nota upplýsingar sem safnað er með því að stöðva netbeiðnir, fá svör við spurningunum „Hver ​​er að hafa samband við hvern?“, „Hvaða útgáfa af þjónustunni er að upplifa mistök?” og svo framvegis. Almennt séð skaltu kanna getu Kiali áður en þú ferð í sjónræna mælikvarða með Grafana.

Grafana: sjónræn mæling
Mælingarnar sem safnað er í Istio enda í Prometheus og eru sýndar með Grafana. Til að komast í Grafana admin viðmótið skaltu keyra skipunina hér að neðan og opna síðan http://localhost:3000/:

Með því að smella á valmyndina Heim efst til vinstri og veldu Istio þjónustuborð efst í vinstra horninu, byrjaðu á þjónustu sa-vef-apptil að skoða söfnuð mæligildi:

Hér er beðið eftir tómri og algjörlega leiðinlegri frammistöðu - stjórnendur munu aldrei samþykkja þetta. Við skulum búa til lítið álag með eftirfarandi skipun:

Núna erum við með miklu fallegri línurit, auk þeirra, frábæru tækin Prometheus til að fylgjast með og Grafana til að sjá mælikvarða, sem gerir okkur kleift að fræðast um frammistöðu, heilsufar, umbætur / hnignun þjónustu með tímanum.
Að lokum skulum við skoða rekja beiðni í þjónustu.
Jaeger: rekja
Við munum þurfa að rekja, því því meiri þjónustu sem við höfum, því erfiðara er að komast að orsök bilunarinnar. Við skulum skoða einfalt mál úr myndinni hér að neðan:


Dæmigert dæmi um beiðni sem mistókst af handahófi
Beiðni kemur, fellur - hver er ástæðan? Fyrsta þjónusta? Eða sá seinni? Það eru undantekningar í báðum - við skulum skoða loga hvers og eins. Hversu oft hefur þú lent í þessu? Starf okkar er meira eins og hugbúnaðarspæjarar en verktaki...
Þetta er útbreitt vandamál í örþjónustum og er leyst með dreifðum rekjanleikakerfum, þar sem þjónustur senda einstakan haus hver til annarrar, eftir það er þessum upplýsingum vísað til rakningarkerfisins þar sem þær eru bornar saman við beiðnigögnin. Hér er mynd:


TraceId er notað til að auðkenna beiðnina
Istio notar Jaeger Tracer, sem útfærir seljanda-óháða OpenTracing API ramma. Þú getur fengið aðgang að Jaeger notendaviðmótinu með eftirfarandi skipun:

Farðu nú til http://localhost:16686/ og veldu þjónustu sa-vef-app. Ef þjónustan er ekki sýnd í fellivalmyndinni skaltu sýna/búa til virkni á síðunni og uppfæra viðmótið. Eftir það smelltu á hnappinn Finndu spor, sem mun sýna nýjustu ummerkin - veldu hvaða sem er - nákvæmar upplýsingar um öll ummerki munu birtast:

Þetta spor sýnir:

 Beiðnin kemur inn istio-ingressgateway (þetta er fyrsta samskiptin við eina af þjónustunum og Trace ID er búið til fyrir beiðnina), eftir það sendir gáttin beiðnina til þjónustunnar sa-vef-app.
 Í þjónustu sa-vef-app beiðnin er tekin upp af sendibílnum, "barn" er búið til í spaninu (þess vegna sjáum við það í sporum) og vísað í gáminn sa-vef-app. (Span - rökrétt vinnueining í Jaeger, sem hefur nafn, upphafstíma aðgerðarinnar og lengd hennar. Hægt er að hreiðra og panta spennur. Stýrt óhringlaga línurit yfir spanna myndar ummerki. — ca. þýðing.)
 Hér er beiðnin afgreidd með aðferðinni tilfinningagreining. Þessi ummerki eru þegar búin til af forritinu, þ.e. þeir kröfðust kóðabreytinga.
 Frá þessari stundu er POST beiðni hafin í sa-rökfræði. Rekja auðkenni verður að senda frá sa-vef-app.
 ...

Athugið: Í skrefi 4 ætti forritið að sjá hausana sem eru búnir til af Istio og senda þá til síðari beiðna eins og sýnt er á myndinni hér að neðan:


(A) Framsending hausa er á ábyrgð Istio; (B) Þjónusta ber ábyrgð á hausum
Istio vinnur mest af því að... býr til hausa fyrir innkomnar beiðnir, býr til nýtt span í hverri hliðarþjónustu og sendir þær áfram. Hins vegar, án þess að vinna með hausa inni í þjónustu, tapast öll rakningarslóð beiðninnar.
Eftirfarandi hausa verður að hafa í huga (framsent):

Þetta er ekki erfitt verkefni, en til að einfalda framkvæmd þess er nú þegar mörg bókasöfn - til dæmis, í sa-web-app þjónustunni, sendir RestTemplate viðskiptavinurinn þessa hausa áfram ef þú bætir einfaldlega Jaeger og OpenTracing bókasöfnunum við ósjálfstæði þess.
Athugaðu að Sentiment Analysis forritið sýnir útfærslur í Flask, Spring og ASP.NET Core.
Nú þegar það er ljóst hvað við fáum úr kassanum (eða næstum úr kassanum), skulum skoða fínstillta leið, netumferðarstjórnun, öryggi o.s.frv.!
Athugið. þýð.: Lestu um þetta í næsta hluta efnis á Istio frá Rinor Maloku, þýðingar á því munu fylgja á blogginu okkar á næstunni. UPDATE (14. mars): Önnur hluti þegar birt.
PS frá þýðanda
Lestu líka á blogginu okkar:

 "Aftur í örþjónustur með Istio": hluti 2 (leiðaráætlun, umferðareftirlit), hluti 3 (staðfesting og heimild);
 «Conduit - léttur þjónustunet fyrir Kubernetes»;
 «Hvað er þjónustunet og hvers vegna þarf ég það [fyrir skýjaforrit með örþjónustu]?»;
 «Myndskreytt leiðarvísir um netkerfi í Kubernetes. Hlutir 1 og 2»;
 «Hvernig endaði þessi hliðarvagnagámur hér [í Kubernetes]?'.

Heimild: www.habr.com